Author: Manzella
san francisco (but actually oakland), software engineer, also into hiking, kayaking, and writing
was looking into some EU payments legislature and rediscovered the following delightful (that doesn’t sound sincere but istg it is) congressional research service whitepaper from 2019, U.S. Payment System Policy Issues: Faster Payments and Innovation.
this quote initially caught my eye: “In August 2019, the Fed announced plans to create an interbank real-time payments (RTP) system by 2023 or 2024.”
now that it’s 2021, i’m really interested to see how that plan evolves (and more broadly, how instant payments shape up) in the U.S. over the next few years. i’m curious what the ramifications of an RTP will be for TPPs like PayPal, and how the fed entering the game will shape related payments legislature (especially around high-risk payment processing). i’m also trying to be optimistic that, from an engineering standpoint, we’ll end up with less kafkaesque interface solutions than (for example) the xml apis i was dealing with from experian as recently as 2018. lol. tbd!
what makes someone a good engineer? how do you “level up” your engineering?
hot take. consider: communication.
the problems of software engineering are fundamentally problems of communication — how do you make different services talk to each other? how do you send information, surface it, transform it, and store it in ways that protect its integrity and function reliably? how do you write code that is self-explanatory? how do you build tools that are flexible, extendible, and can be understood by other engineers? these are all technical communication problems, and yet! there’s a terrible “toastmasters”-esque connotation that clings to the idea of communication when surfaced in engineering spaces.
one of my favorite quotes is from the playwright george bernard shaw: “the single biggest problem in communication is the illusion that it has taken place.”
hm. have you ever misunderstood what a reviewer was trying to communicate in a comment on your PR, or vice versa? have you ever sat in a design review and listened as multiple engineers seemed to be participating in entirely different conversations on the same topic at the same time?
effective communication can ameliorate the pains of a struggling project, clarify legacy code, and increase engineering trust (internally and with other teams). lack of effective communication, conversely, can tank the best teams — if a project’s chief architect cannot achieve buy-in or effectively delegate work, it doesn’t much matter how good their design is. as much as most of us got into engineering to not be in meetings and not be talking all day, it turns out that engineering is still a team sport, and an incredibly technically demanding one at that.
finally, circling back to the first question: what makes someone a good engineer?
well, good feedback helps. “situation, behavior, impact” is a useful organizational framework for delivering useful, actionable, kind feedback. if you struggle with effective communication as an engineering manager, your engineers will struggle too.
effective technical communication is not a “soft skill,” and it’s not “below us” as engineers. in fact, since we are responsible for building the structures whereby everyone communicates, it behooves us to excel in communication in order to excel as engineers.
The more I consider this topic the more I think I have to say, but I’ll start with something simple — the two kinds of medium/LifeHacker/whatever posts that pop up on my Google news feed and drive me up the wall.
- Start Coding and Change Your Career with 75% off this Python course bundle
- Here’s how I changed my life and became a web developer in 5 months
In regard to the first — I have paid for one of those bundles because “what the hell, worth a shot.” You can access the same information for free elsewhere and literally no one single bundle will teach you all (or even most) of the things you need to know to be a software engineer. If you’re getting your feet wet, I would instead recommend any of the following:
- Computer Science 101 from Stanford (self-paced)
- Learn Python the Hard Way
- Grokking Algorithms (amazing book, particularly if you’re a visual learner)
- Cracking the Coding Interview
- Python For Everybody (UMich 5-part specialization)
- The Bash Academy
- CodeFights, Hackerrank, Codecademy, pramp, etc
- Reading documentation! Stackoverflow! Familiarize yourself with the terminal, virtual environments, basic OOP principles, and prepare to learn a lot of jargon.
The reason I recommend these so much more than just buying a bundle is that I think you’re going to have the same barrier to entry with a bundle as you do without one. A bundle gives you a bunch of information but that knowledge won’t necessarily stick with you if you don’t have an application for it — it’s hard to get started if you don’t have a project or a particular thing in mind that you want to understand or build. You can find everything you need on the web, for free, and if you’re looking for something that helps you get the ball rolling I think starting with an intro course is a much nicer way to test the waters than plunging right into an “all inclusive” bundle that will just pummel you with facts that could or could not be relevant to what you actually might end up wanting to build.
I think it’s also easy to get overwhelmed by how much a) everyone else seems to know that you don’t and b) simply how much information is out there. Where do you start? What do you prioritize? I remember when I was getting started, I had never interacted with the terminal before and well-intentioned engineers were expressing shock that I didn’t have tmux. I spent 4 hours down that rabbit hole when I really should have focused on understanding basic functionality (chmod, chown, sudo, etc.) in that moment instead. This ties into the issue I have with bundles because again, it’s like asking for a glass of water and getting a deluge. Take it step by step! And bonus, save your money. If you really feel the need to burn cash, buy the full version of SublimeText3 so you won’t get interrupted with warnings about the “demo limitations” for the next year (ST3 is a nice text editor with a lot of features/customizations/support! Speaking of, if you get started with that, you’ll want to install the Package Control add-on, and a linter for whatever your chosen language is).
Second issue is the “Here’s how I achieved in 5 months what other humans spend 4 years in school learning to do” blog post. This is just bullshit. If you’re starting from zero, you might build a React app and have a decent grasp on an OOP language or two in 5 months. You will not be an engineer. That’s ok, but don’t think you’re going to be designing amazing web apps, reversing BSTs, and landing a job at Google if you spend half a year learning software development. Engineering skills are different from development skills for one thing, and for folks without STEM backgrounds, learning the latter is probably going to come easier than the former, but learning both is vital to actually being a good engineer. Also, I have interviewed folks that came out of the best-regarded coding bootcamps (ie. Hack Reactor) — intensive full-time 6 week courses, mind you — who couldn’t start to explain class inheritance or reverse a string. This shit takes time. There’s a lot to learn — but that’s ok, and if you’re interested in programming, misleading medium posts selling snake-oil and “a new lease on life in 3 easy steps” should not discourage you from starting on this path.
Anyway, that’s my rant for now. Go forth and code, it’s fun!*
*Also infuriatingly frustrating, painstaking, putsy, and 100% worth it.
Engineers have opinions, and the best way to back yours up is by pointing to someone else on the internet who agrees (right?).
Here are, in no particular order, resources i’ve found helpful at various points:
- Crontab Guru
- Crons are one of those things that you probably write just frequently enough to forget the syntax every time. This’ll help.
- Regexr
- Similar idea as above, but for regular expressions.
- Can I use
- See which browsers and OS support what
- Swagger (OpenAPI)
- designing an API? you’ll need a contract. OpenAPI can help.
- Swimlanes
- If you need sequencing diagrams, but don’t need something as heavyweight as lucidchart, swimlanes is for you
- Choosing an HTTP Code
- Wondering what Response to return? Check this out, great flowcharts included.
- JavaScript Equality Table
- Explaining strict comparisons to a junior dev? Wanting to understand them better yourself? This visual aid is really slick.
WIP!
First thing’s first, don’t install things using sudo with pip!! Poor form, and as of mavericks, nigh impossible. You shouldn’t be overriding the system files anyway. Instead, if you want to develop, run a virtual environment. It’s easy to get started.
mkdir my_virtual_environmentPip install virtualenvvirtualenv my_virtual_environmentsource venv/bin/activatePip install python(and so on and so forth)
In a new app project, if you’re going to use any frameworks dependent on node/npm, make sure you have packages.json included in your project directory!
You can create this file by doing npm init.
All the packages.json file really requires is a name and version — however, you might see an error when you try to use npm from the command line afterward: repo not found. If that’s the case, add the following to package.json:
“repository”: {
“private”: true
},
Boom!
When I was getting started with git, I developed a “greatest hits” of commands and ideas that helped me understand what was going on. Here are a few of them — more to be added.
- Whatever else you do, remember that commits are forever! If you make a mistake, don’t think of it as ‘deleting’ the commit. You’re just pushing a new commit with new code that cancels out the old commit’s work. The more comfortable you are with this though, the better — for reverting, cherry picking, etc.
- Change the name of a commit you just made:
git commit --amend - Cherry pick a set of commits:
git cherry-pick A^..Bwhere A is the oldest commit you want and B is the newest. This is inclusive! If you want A through B excluding A and B, just useA..B. - Undo your last commit (only if you haven’t pushed!!):
git reset HEAD~ - Undo a commit you already pushed:
git revert commit_name- Never use
rebaseon a commit that’s already been pushed especially in a shared repository! Rebase rewrites history, and that’s not clean, sustainable, or kind to your teammates 😉
- Never use
- To bring your feature branch up-to-date with a base branch (e.g., develop or master):
git checkout developgit pullgit checkout feature/your_feature_branchgit merge --no-ff develop
- To remove untracked files, use
git clean -f. Add the-dtag if you want to remove untracked directories as well. - Don’t revert
mergecommits! This is a fast way to mess up your history. Reverting a bunch of individual commits can seem like a pain, but it takes less time than trying to undo amergereversion. - This is also a great resource for undoing (almost) everything in Git.
More later!
east bay afk 