The discussion about developer productivity (see: here) led me to following Paulo André, who recently posted:
The secret to productivity hiding in plain sight:
The fastest way to complete two projects that use the same resources is to do them one at a time.
It’s 2023 and most still pretend otherwise.
I initially read this incorrectly (use resources one at a time??) and I thought it was a criticism of pair programming. Then I read it correctly.
First of all, I absolutely agree. As most of the comments say, multitasking is so last century. If someone tells me they’re great at multitasking, I’m more likely to offer them advice than applause.
However, now I’m wondering if Paulo’s comment is or isn’t an endorsement of pair programming, regardless of whether Paulo had that in mind.
A search for “pair programming” got me this, in round one. Photo by Michael Hoyt on Unsplash
Clearly one brain trying to multitask on multiple pieces of work is using “the same resources,” but what about two brains with multiple pieces of work? From the perspective of the team, wouldn’t all of the developers on the team be considered “the same resources”?
I’m leaning towards the analogy faltering as more brains are added. The limit on WIP (work in progress) isn’t always “one” nor is it necessarily “the same as the number of developers.”
Maybe put another way: speed isn’t the only benefit of pair programming. Developers learn from each other, code review is inherent, knowledge of the code is shared.
Folks who are new to software development sometimes ask me about my career path. The first time I fielded this question, I told my story in a straightforward way. Hearing myself talk, though, I realized: this way of telling my story is probably not a good idea.
This is not an actual illustration of my career path. Photo by Jack Anstey on Unsplash
People who ask me this question are often actually asking me about their own career path. They see where I’ve landed, and perhaps they imagine they want to land somewhere similar. They might be comparing their path to my own, perhaps to see if they might make some of the same steps that I’ve made along the way.
And my route is almost certainly not the route for someone else.
Step one: pay a utility bill
First and foremost: my story starts with my first tech job, in 1996… or maybe before that, with my undergraduate major in English… or even before that, with my first computer experiences as a kid learning BASIC on Commodore 64s and TRS-80s.
I may have been using computers since I was a kid, but I sure wasn’t carrying one in my pocket until well after I graduated from college. If you were carrying a smartphone when you were single-digit age, we have grown up in very different times. That’s significant. If I wanted to learn how to program a computer, I had to go somewhere that had computers and take a class.
Also, my first job in tech WAS in 1996 — during the “dot com bubble” days. I stumbled into it by trying to pay my gas bill online. The gas company didn’t have a website, so their URL went instead to the small local internet company that was hosting the domain. I poked around the site, discovered that the internet company was hiring for tech support, and I applied. As my boss from that company later told me, “you had the customer service skills, we could teach you the rest.”
You may be starting to see why I don’t recommend that you follow my path. Getting a job by trying to pay a utility bill online and inadvertently stumbling into a company that will train you is not a great career plan.
Step two: impulse buy an education
I moved from tech support to abuse handling (canceling spammer accounts, yay!) to network engineering. Then 2001 happened, the dot com bubble burst, and I got laid off, along with a lot of other people.
I quickly discovered that nobody was hiring the sort of network engineer I was, at least not at the junior-to-intermediate level I was at. They wanted people who could route network traffic within an office building. I only knew how to route network traffic between major cities.
One fine Sunday, while still unemployed, I started to toy with the idea of going back to school. Maybe not for a full degree, but just to get some other interesting tech experience. Worcester Polytechnic Institute offered a several-months-long graduate certificate program in UNIX, C, and C++. I knew some UNIX, and I had a lot of time on my hands. I submitted the “request more info” form.
Later that day, I was out on a bike ride when I got a call back (on my flip phone!) from WPI. The nice lady described the program. It sounded interesting. I explained my background, she thought it was a match for them. I asked when it would be offered next. I could hear her typing. The next round would start [clickety clickety]… on Monday morning. Less than 24 hours later.
I told her I didn’t know how I’d pay for it. She said we’d figure that out when I got there, and if I could arrive early, I could complete the paperwork then. So yeah, I impulse-bought a graduate certificate program while on a bike ride. If you weren’t already convinced that you shouldn’t follow in my footsteps…
To be fair, it worked out. I rediscovered that I still loved programming. But you could perhaps do a bit more research than I did, to better effect.
Step three: work somewhere for a year or sixteen
I was tutoring a fellow classmate during that program, so when he got a job somewhere, I thought “hey, if he can, and I was tutoring him, then I can…” That company had proprietary software, written in a proprietary language, on a proprietary operating system. I was pretty sure I wouldn’t stay longer than a year.
I didn’t stay for a year. I stayed for sixteen years.
I started as a service programmer, which mostly meant troubleshooting problems and fixing bugs with manual code patches. I got promoted. I went back to school, doing an undergraduate certificate in Computer Science. It was perfect — all the coursework I had missed from being an English major, without having to get a full bachelor’s degree again. It was also entertaining, as a senior programmer, to tell my boss I was taking an intro to programming class. 😉
I moved on to being a developer, which was more about working on new features for an application (but still troubleshooting and fixing bugs with manual code patches). I got promoted again. Eventually, though, I really wanted to learn mainstream technologies.
So I went back to school, again.
Step four: go overboard
You know, if you want to be a web developer, even a full stack developer, I’m not at all convinced that you need a master’s degree in software development. Some places will hire you without a degree, some will insist on a bachelor’s degree, but a master’s degree? It’s debatable whether or not I went overboard with that.
I had tuition reimbursement, so work paid for about half of it. And that — plus 16 years as a dev — probably did enable me to come to my current employer at a higher level than I might have otherwise. Also, I am not great about sticking with a self-driven program, but put me in an academic setting, and I’ll slay it (I had a 4.0).
However, if I wasn’t already cringing at telling you my bizarre and improbable story, I’m definitely cringing to tell you about the master’s degree. I don’t want people who are just starting out to think “OMG, to get to where I want to go, I need 25+ years in tech and a master’s degree?? I’m never going to get there.”
But “there” (where I am) isn’t where you want to go. Because here’s the ultimate reason why you shouldn’t follow my path: you’re not me.
Step zero: take your own steps
My path has given me a unique combination of skills, perspectives, and experiences. Do they make me extremely well-qualified to do what I do? I sure think so.
But here’s the secret: I’m doing what I’m doing because I enjoy it… and I’m qualified to do this job that I enjoy because, for 25+ years, I’ve just kept doing, and getting better at, what I enjoy doing.
I didn’t know “what I wanted to be when I grew up” until my late 20s, when I impulse bought that graduate certificate and remembered that I loved programming. Even then, I didn’t know what I wanted to focus on. I tried stuff out. In the process, I discovered what isn’t for me, like network engineering, low-level programming languages, and CSS.
The chances are slim that you want to do exactly what I do. You can see my experience or my title and guess what I do, but unless you’re my manager, you likely have inaccurate guesses about what I actually do. If you do think you find my role appealing, answer this: what do you imagine that I do? What most interests you about that?
Just like how my own starting point is probably not like yours, my own current role is probably not your true target. Therefore, how I got from my “Start” to my “Here” — while perhaps a fine story — is not nearly as useful to you as working out your own path to get from where you are now to your own destination.
“Follow your heart” isn’t quite what I’m recommending here. I’m suggesting something more down-to-earth. Try stuff that appeals to you. Figure out what you most enjoy doing — and, ideally, how you can get paid to do it. Then, do more of that, for as long as you continue to like it. When you get annoyed or bored (or laid off), stop and assess where you want to go next.
Uncle Sidney was notorious. I think even he’d agree to that.
Sidney was his own weather system, with lots of thunder. Photo by Johannes Plenio on Unsplash
He might indeed be someone’s uncle, but he isn’t my uncle or the uncle of anyone I know.
He was the main instructor for one of the programming languages used (and created!) by one of my former employers. But if you said Uncle Sidney, everyone within earshot of him knew who you meant. Sidney was his own weather system, with lots of thunder.
His reputation preceded him, for everyone’s safety.
Portrait of Sidney
Likely in the same moment in which you were signed up for Sidney’s class, you were warned that you DO NOT under any circumstances show up late for class. Leave home an hour early, if you have to. Don’t be late. Your manager will hear about it, loudly and in no uncertain terms.
His insistence on timeliness wasn’t pure whim, or even simply a matter of respect. He had the timing of every day of his class down to the minute. If you delayed the start of class, that would throw him off schedule. And there was no “just start without me, I’ll catch up” in this world. This class was intense, and he needed you on board and attentive for every minute.
Second thing you learned: don’t fall asleep in class. I did this once. You better believe he noticed, stopped the class, and called me on it — loudly, crossly, but not unkindly. We took a short break. Again, he needed our attention for every minute.
The stories could go on and on. Some of the stories were not so great. “Sidney yells because he cares,” we’d say. It helped me to think of being yelled at as a badge of honor, but not everyone can let shouting roll off them like water from the back of a duck.
Some stories were more entertaining. My favorite moment was when he quipped that Friday was actually “fried day” because people were fried by then… and then he laughed so much at his own corny joke that he couldn’t continue class for at least a full minute. Which, of course, threw him off schedule.
I emerged from those classes reasonably conversant with the programming language. It’s been years since I last used it, and most of my knowledge of the language is gone now. However, several other lessons from Sidney stick with me.
Slow down, smart people
I find myself repeating this one as I’m mentoring: smart people have a tendency to rush, especially by jumping to conclusions. We’re gratified to put some of the puzzle pieces together and think we see the whole picture. We see A and B, and we get excited. We immediately decide F and G, therefore K… skipping a bunch of intermediate steps. Then when K doesn’t turn out to be true, we’re confused and stuck.
The answer is often to rewind and start again with A, taking it one step at a time. A, then B, then C, then D… wait, what about E? It turns out E isn’t true after all, which explains why K was a faulty conclusion.
Here’s a concrete example. Let’s say a specific input to a function should be generating a certain output, but it isn’t. We stare at the function, and we don’t see how we could possibly be getting the results we are seeing, given the input we’re passing in — or more accurately, given the input we assume we’re passing in.
Slow down a bit. Check to see if the values we’re passing in are what we expect. They are. Slow down a bit more. Are the values we’re passing to the function the same as what the function is receiving? “How could they not be??” you might ask. Check anyway. Wait, they’re not… I pass 5 and 100 and the function is receiving 0 and 0?? How can THAT be?
And that’s exactly the reason for slowing down: you’ll find those problems that exist in the cracks, in places where you assumed everything was going according to plan. Maybe you never saved your most recent code changes, so the code that is running isn’t the same as what’s on your screen. No wonder E isn’t true.
Sidney took this a step further, calling me out on my tendency to try to write down everything. He would provide us with notes, he promised. Try putting the pen and paper aside and just listening. Just absorb the ideas and make sure you understand. Too much writing, especially in a class as fast-paced as his, and you might start to miss the current idea because you’re too busy trying to record the previous idea. This can snowball quickly.
Ask the question ASAP
If I’m listening to someone lecture, I often hold a question in my mind, rather than asking it. I am trying to allow for the possibility that they’re going to explain it momentarily, or that I have all the information and I just need to make some mental leap to understanding. This is not a great habit.
With some lectures, the information is cumulative. If you don’t understand the point that was just made, you are going to be confused by the point currently being made, baffled by the point coming next, and completely lost in a matter of minutes. And at that point, it can become hard to admit that you actually lost the teacher several minutes prior and you need them to recap a lot.
Put another way: the best time to ask is as soon as you have the question, or as soon as you realize you’re confused. The next best time to ask is when you’re kicking yourself for not having asked because you’re now completely lost. As challenging as it is to confess being lost, it’s only going to get worse the longer you stay lost.
Could you teach it?
Related to the point about asking the question right away: one of Sidney’s tricks was to ask the class if we all understood something. Are we sure we all completely understood it… yes, nods all around.
Okay, he’d say, then explain it back to me.
Uh oh. Suddenly, we’re not sure we understood it so well after all. Oops.
It’s not necessary that you understand everything perfectly on the first try, or that you could explain it to others after just one hearing. It is definitely useful to know that there are layers of understanding, and to know when you might be expected to be at a deeper layer than you are. Now, I routinely check my understanding: did I just barely follow what I was being told? Could I explain it to someone else if they asked? If not, what do I need to ask to get clarification? Or is my minimal understanding sufficient for now?
You influence others too
Uncle Sidney retired before I left that company. On his last day, I made sure to catch up with him to say my goodbyes and wish him well in his retirement.
And it really hit me — as one of the original developers of that language, he’d taught “generations” of developers how to reason about it. He’d taught us how to slow down, skip the note-taking sometimes, ask the questions, and check our understanding. And everyone who taught the language would do so in his footsteps as well, even if their approaches and teaching styles were entirely different. In that way, his influence on the organization was not so unlike an uncle after all.
What’s your legacy, and what do you hope it will be? When you move on from where you are now, what will people remember about you? What habits will they pick up from you, what lessons did they learn from you, and how did you influence the culture and people around you?
Another post I made a while ago on Medium, but this one I updated today with some newer thoughts.
I once had a colleague who (jokingly) left this comment on a code review, and not in reference to a specific line of code:
“Missing semicolon.”
Photo by Nubelson Fernandes on Unsplash
Case study two
I once had a QA colleague who reported a bug to me in some code I had just written.
I made a code fix, but he said it was still broken.
Another fix, still broken.
Another, still broken.
Then he messaged me: “Never mind! User error!” and explained what he’d done wrong.
I think of both of these case studies often.
This post originally ended here, with “Yeah, that’s the whole post :)” when I posted it as “Ghost errors” on Medium on 24 August 2023. But I’m posting it again in 2025, and there’s more to say.
First of all…
What the above case studies have in common: reviewing something again, even if you’re not entirely sure what you’re looking for, can be a good thing.
My reviewer colleague was joking about the missing semicolon. I think. Maybe I should just look through the code one more time.
And my QA colleague was not joking, but the “bug” he was reporting was not actually a malfunction of the software (although it was arguably a design issue if even someone so knowledgeable about the product would be using it “wrong”). Regardless, it led to my finding and fixing three other problems that neither of us realized were there.
Case study three
A colleague recently was working on an application that had a bug that only happened at a certain time of day. He asked his AI coding assistant tool to write him a set of tests to test all the places in the code where time of day was a factor.
And one of those tests failed.
Questions
Have you ever gone into your code to look for a bug that wasn’t actually there – but in the process, you’ve found some other things that need fixing?
Wonder what happens if we send our AI assistants into our code to identify the bugs for us? Have you tried this? I’ve tried asking my coding assistant for suggestions on improving the code, but I haven’t said “there are some bugs in this code, please identify them and suggest fixes.”
And here’s the question most on my mind right now:
Do we lose something in using the AI tools? Is this the equivalent of using a dirt mover instead of using shovels – more powerful, less toil but also less exercise, probably better in some circumstances? What am I doing to keep myself in shape in case I need to pick up a (code debugging) “shovel” someday?
DevOps Enterprise Summit 2022 closed with a great talk from Forrest Brazeal. As a cloud architect, musician, writer, and cartoonist, he’s got an impressive resume of his own, but he also has a project to help aspiring cloud engineers improve their skills and their resume.
Forrest’s Cloud Resume Challenge is a set of steps for building oneself an online resume using a variety pack of cloud technologies. It’s enough guidance to tell someone what to do, and not too much guidance on how to do it, which suits me just fine. There are a lot of good tutorials online to fill in any gaps. Forrest’s work gets people past the “I have no idea where to start” point, onward to the “hmm… how would I do that?” point, where curiosity can take over.
I learn best by doing. Watching someone demo or listening to a lecture only gets me so far. I need to twist the knobs and see what they do, break and fix things several times, go down a few dead ends and have to retrace my steps back. Granted, it can be frustrating — for example, breaking my site that WAS working, and not being able to spot what I’d done to make AWS unhappy. It’s also reminding me just how much I’ve forgotten (CSS…) in a few years of disuse, which is humbling. But it’s all overshadowed for me by how satisfying it is to try out a technology I’ve never used before (like CloudFront) and make it work.
Here’s Forrest’s talk from the Summit: Transformed! A Musical DevOps Journey. (Registration is free and will get you 10 free videos per month from past conferences — the videos are great, well worth getting on a mailing list.)
When I first learned about APIs, all I ever heard for a definition was what the letters stood for: Application Programming Interface. As if that told me anything useful.
The only “what it stands for” that I’ve found less useful was learning what REST stands for, as in “REST APIs”. That expansion is so useless to me that I’m not even going to share it here.
If you didn’t know REST, did you go look it up? Am I right or what??
An interface is an agreement
So what is an Application Programming Interface? Let’s start with the “interface” part. When you hear that word, think “agreement”.
You have an agreement with your microwave. When you press ‘3’ and ‘0’ and ‘Start’, your microwave will respond in a predictable way: it will start heating your food and maybe spin a carousel, it will display a countdown timer for 30 seconds, and it will beep when the time’s up.
This agreement, and the keyboard (and display and beeping) that let it be executed, are the interface. Specifically, this is a user interface, because you are the user of the microwave.
So far, so good?
The programmer’s agreement
Now, let’s say you have an app on your mobile device that lets you control your microwave. I don’t know why you’d want to do this. This sounds like a recipe for overcooked food, or a mess splattered all over your microwave. But let’s say that’s what you have.
Just going to heat up my coffee… from the next room. (Photo by Paul Hanaoka on Unsplash)
You now press ‘3’ and ‘0’ and ‘Start’ on your phone, and your microwave responds. There’s still a user interface here — the interface between you and the phone is the user interface.
But there’s also another interface here: between the mobile app and the microwave. There’s an agreement between the developers of the mobile app and the developers of the microwave: when the app sends data in a specific format to the microwave, the microwave will do stuff, and maybe even send some data back to the mobile app when it’s done.
That’s not a user interface, between the app and the microwave. That’s a programming interface… an application programming interface. An API.
Is it “an API” or “APIs”?
One more thing to know: people play fast and loose with the term “API”. It is used to refer to the overall interface between two systems. It can also be used to refer to a specific subset of the interface, which could also be called an endpoint: maybe the microwave has a “cook” API, a “set timer” API, and a “toggle light” API for that light I always wish was brighter when I’m standing at the stove making dinner. And these APIs are part of the larger API. 🙃
In case that wasn’t enough, a server that provides the API might also be called an API. As in: “the microwave API [server] is down, so the APIs [the actual endpoints] aren’t responding, and the app won’t work.” Fortunately, you can usually figure it out from context.
Did this clarify things for you? Do you have a real world use case for the ability to microwave something while not physically present in front of the microwave? What other abbreviations do you know where just knowing what the letters stood for didn’t help much at all in understanding what it means? And shout out any good resources you know for understanding what REST APIs actually are!
Naming things is hard. One of the hardest things in computer science, as the saying goes.
I once spent a full day trying to find the perfect name. Does that seem excessive? Well, consider these factors:
I was coding a major feature of the application. All users, whether they were customers or colleagues, would use whatever name I chose. It would even be an option on the main menu.
A large part of the codebase would also use the name. Developers would see it a lot.
I refused to choose an obscure name or a name so long that it would get abbreviated. Nobody should have to ask what it meant.
Many potential names were already in common use for related, but not identical, concepts. Some of those names would even appear on the same screens.
I finally found the perfect name. We integrated it into the application design, the code, and the way we talked and thought about that feature.
You know where this is going, don’t you…
Many months later, we changed one of the tools we used as developers. The new tool used the same name for yet another related, but not identical, concept. 😭 After much agonizing, we changed the name of the feature, and I spent another full day updating every reference to it across the entire application and all of our documentation.
So, as someone experienced in the sport of naming things, I can help. Let me make it easier for you.
S
That’s right… S.
True story: I once spent hours trying to troubleshoot a program where all of the variables had single letter names. By the time I figured out how C, D, E, H, P, M, N, R, S, and W all fit together, I had forgotten what I was looking for and why.
Also, it was causing a production issue, and it was several hours past my bedtime. I was groggy and desperately trying to fix everything before user traffic started to pick up in the early morning hours.
“It seemed like a good idea at the time,” the code’s author said when I confronted him about it the next day. 😠
Would it help to have comments telling you what C, D, E, H, P, M, N, R, S, and W all represent? Maybe, but sooner or later someone’s going to change the code without updating the comments, and then the outdated comments might actually make things more confusing.
So, rule one: No single letter variables. Please and thank you.
The only exception might be a small for loop where it’s clear that c or i is a simple counter, like this:
for (let i = 0; i < 9; i++) ...
Otherwise, please call a spade a spade, not an S.
Say what you mean
That said, info is not much better than i. Info about what? You can do better than that.
92.84% of the time, adding info and data and details doesn’t contribute to the conversation. It’s okay for customer to refer to an object with all the details about the customer. You don’t need to call it customerDetails or customerInfo. Think of how much nicer it will look when you use dot notation: customer.firstName beats customerData.firstName.
Granted, 7.something% of the time (I can’t be bothered to do the math on my made-up statistic), you won’t have a choice. You have to differentiate between customer and customerDetails, and there’s just no getting around it. You’ll know those times when you see them. Keep it simple until the code strong-arms you into doing otherwise.
Rule two, then: call a spade a spade, not a digToolInfo.
Someone using a digToolInfo to unsettle() some plantingSubstrate. (Photo by Anaya Katlego on Unsplash)
Keep it short
You don’t call the bank and ask “what is the current value of the total amount of money in my account?” You don’t call the bank at all these days, but that’s beside the point. You’d just ask: “what’s my balance?” No need to call it currentValueOfTheTotalAmountOfMoneyInTheAccount when it’s a balance.
It might be a currentBalance if you need to distinguish it from some other kind of balance — previousBalance, maybe, or projectedBalance. If balance is just as clear, though, use it.
How DO people get their bank balances these days, anyway? I log in to my bank website and look it up, but I bet by now that’s old school. Probably you record a video of yourself dancing to a song about your bank balance and post it to TikTok, and a bot from your bank will text you with the value and a relevant movie clip as commentary.
Rule three: it isn’t acompactToolUsedForDiggingInOrderToPlantInTheGarden.
Okay, I think you’re getting the idea. Call that spade a spade, and you’re good to go.
Have you ever had to deal with code that just made no sense? Did you get angry at whoever wrote that garbage, only to look it up and find that you wrote it, six months prior? I feel you. Worst programmer ever is Me From The Past.
Think of it this way instead: you’re so much better of a programmer now than you were six months ago! Learning and growing, that’s how you’re rocking it. Go you!
