A day in the life of a software engineer— Giphy and quotes edition

Tudor Barbu
Jul 6 · 7 min read

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.

Image for post
Image for post
Inspirational AF

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.

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)

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.

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!?

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

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.

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.

… 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

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

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.

Work is the curse of the drinking classes― Oscar Wilde

Nothing washes away the problems of the day as an after-work beer.

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!

Dev Genius

Coding, Tutorials, News, UX, UI and much more related to development

By Dev Genius

The best stories sent monthly to your email. Take a look

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Tudor Barbu

Written by

Trust me, I used to be an engineer!

Dev Genius

Coding, Tutorials, News, UX, UI and much more related to development

Tudor Barbu

Written by

Trust me, I used to be an engineer!

Dev Genius

Coding, Tutorials, News, UX, UI and much more related to development

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store