A day in the life of a software engineer— Giphy and quotes edition
I enjoy reading quotes from famous thinkers from time to time. It’s like accessing concentrated wisdom, packed in a couple of phrases. Without any boring details. One either gets it or doesn’t. They’re like puzzles of the mind, just showing the focal point and allowing me to fill in the blanks and add my own interpretation.
This post is a collection of quotes I find interesting with my own interpretations added to them. However, I will not use the cliché approach of writing them in uppercase on an inspirational background of a sunrise, or someone doing yoga, or a waterfall. Or whatever.
Instead, I will use GIFs to illustrate them and tell the story of a day in the life of a software developer.
9 AM — morning coffee
Programmer — an organism that converts caffeine into software (unknown author)
Personally, I agree more with the “extended version”:
Programmer — an organism that converts caffeine into sarcasm with software as a byproduct (unknown author)
9:30 AM — First code review of the day and seeing that somebody broke the coding standard
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live — John F. Woods
As I said in one of my previous posts, writing code is easy, writing good code is hard. Understanding code is really hard. Understanding bad code is particularly hard.
While having coding and naming standards in place doesn’t mean that all problems will magically go away, it does makes sure that everyone speaks the same language and fewer things get “lost in translation”.
It’s OK to figure out murder mysteries, but you shouldn’t need to figure out code. You should be able to read it — Steve McConnell
Keep it simple! Keep it consistent! Always lint on your code. On pre-commit and before merging. Reject PRs that are difficult to understand. The team will thank you later and future you will be happy.
10:00 AM — Daily standup and the PM announces some “small changes” to half of the tickets
Programmers don’t burn out on hard work, they burn out on change-with-the-wind directives and not “shipping” — Mark Berry
Need I say more!?
10:15 AM — Touching some legacy code with unexpected side effects
We build our computers the way we build our cities — over time, without a plan, on top of ruins — Ellen Ullman
Tens of thousands of pages have been written on the nature of legacy code. What it is exactly, how does it affect the company, how we can prevent it, and how we can mitigate its effects.
There’s a lot of confusion between old code and legacy code. Maintainable old code is not legacy. Unmaintainable new code is. I had some experiences in the past when our code was legacy before reaching production. It wasn’t written 5 years ago, it was written last week. It just sucked!
Unmaintainable code is code that every time it’s changed, it produces some unexpected side-effects. Sometimes elsewhere in the application. And it turns even the simplest new feature request in an interminable game of whack-a-mole with weird bugs. The best way to mitigate it and avoid legacy is clean architecture, proper encapsulation, separation of concerns, and tests. Which brings us to:
To me, legacy code is simply code without tests. I’ve gotten some grief for this definition… I have no problem defining legacy code as code without tests. It is a good working definition, and it points to a solution — Michael Feathers
11:00 AM — Let’s do a partial deployment and add the missing features later
A traditional project manager focuses on following the plan with minimal changes, whereas an agile leader focuses on adapting successfully to inevitable changes — Jim Highsmith
Change is the only constant of our industry. Change and its ever-increasing speed. Architect for change from the start. Agile is not a mindset, agile is a state of the system. And it requires a well-designed architecture that allows for modular development and a pipeline that allows continuous deployment.
1:00 PM —The “Let’s have one quick catch-up meeting!” just before lunch
The best meetings get real work done. When your people learn that your meetings actually accomplish something, they will stop making excuses to be elsewhere — Larry Constantine
Meetings are seen as a waste of time because, well, generally speaking, they kind of are. About 90% of all the meetings I have attended could have been solved with a simple email exchange. And most of them have been solved like that, post-factum.
Then why was I invited to those meetings? I have mirrors in my house so I know for a fact that I wasn't there so that the others can marvel at my good looks.
I think office meetings are the perfect representation of how the road to hell is paved with good intentions. Calling a meeting is done in good faith: it allows everyone to have an opinion, it provides a forum for constructive debates, and in the end, it allows the team to take a binding decision together. Or that’s the theory.
In practice, however, half the people don’t know why they’re there, there’s no clear agenda and the discussion wanders off. And if at the end of a meeting the conclusion is that another meeting is needed to “iron out the details”, the first meeting was a complete waste of time.
I think the 3 most important conditions for a successful meeting are:
- have a clear agenda to start with
- somebody needs to steer the discussion back on topic every time it wanders astray
- somebody — ideally not the same person — needs to take notes and send a minute after the meeting
And don’t schedule meetings right before lunch. Nobody will pay any attention.
2:00 PM — Enjoying a few hours of undisturbed productivity
… programming requires more concentration than other activities. It’s the reason programmers get upset about “quick interruptions” — such interruptions are tantamount to asking a juggler to keep three balls in the air and hold your groceries at the same time — Steve McConnell
Software development is a very immersive creative activity that requires engineers to go into a deep state of flow. Or in “the zone” so to speak. Small 3–5 minutes interruptions are enough to ruin that.
To some extent, creative working is like sleeping — amazing comparison, I know!!! — if somebody wakes you up to ask you a quick question every 20 minutes or so, no matter how easy the answer is, you don’t get any sleep.
The ideal engineer is a composite … he is not a scientist, he is not a mathematician, he is not a sociologist, or a writer; but he may use the knowledge and techniques of any or all of these disciplines in solving engineering problems — N. W. Dougherty
4:45 PM — Somebody finds a bug in production following the partial at deployment from 11:00 AM
If debugging is the process of removing software bugs, then programming must be the process of putting them in — Edsger W. Dijkstra
I’ve said it before and I’ll say it again. Bugs are a fact of life. There is no software development without bugs. They can’t be avoided. But their impact can be minimized.
At the very least, a bug resilient project should have:
And all these come at a cost. They require an initial investment. Quality ain’t cheap.
Quality is the ally of schedule and cost, not their adversary. If we have to sacrifice quality to meet schedule, it’s because we are doing the job wrong from the very beginning — James A. Ward
5:50 PM — The project manager asks for a short email describing the problem
Soft skills get little respect but they will make or break your career — Peggy Klaus
For most of my professional life, I ignored the importance of soft skills and office politics can have on my career. I thought that if I just focus on the code and problem solving, everything will work out just fine. Fuck me, I was wrong!
Being a problem solver is important. Being perceived as a problem solver is i̶m̶p̶o̶r̶t̶a̶n̶t̶e̶r more important. And here is where soft skills come into play. Nobody wants to go to the office’s asshole unless they really have to. No matter how technically strong that person is. In real life, Dr. House would be unemployed and homeless. Asking for help from an expert shouldn’t be a bigger problem than the initial problem.
Answering emails (politely!!!), moving tickets, notifying stakeholders about progress, or following company bureaucracy — annoying as it may be — is a sign of reliability.
6:00 PM — Beer o’clock
Work is the curse of the drinking classes― Oscar Wilde
Nothing washes away the problems of the day as an after-work beer.
11:45 PM — Reboot time
Life would be much easier if I had the source code (unknown)
But we don’t. Some problems can’t be patched. We just need to live with them. And sometimes, we just need to turn ourselves off and on again. Nothing like a good night’s sleep to see things in a new light.
And it the end, my favorite quote of all: Trust me, I’m an engineer!