Embrace your Laziness
Before I began working full-time, I used to believe that a Software Engineer, Programmer, Developer, etc. were all synonymous. They were just various fancy ways to describe one thing - a person who codes with the intention of making stuff. There's nothing that professionals love more than to make up 10 different words to describe the same thing right? Right?!?!
It wasn't until I met my mentor, who I will call Mr. Tapas (yes, like the food cuisine), that I learned one subtle difference between what it means to be a programmer, and what it means to be a software engineer. That subtlety is as follows: Programmers are extremely hard working, Software engineers are lazy.
Put those pitchforks away, hear me out
You might suddenly be outraged by that statement. You may be thinking "YOU'RE A GODDAMN LIAR" or "I'm the most hard-working person I know!"
Believe it or not, it's not a bad thing to be lazy! Being lazy is often seen negatively, and is often mistaken for leisure. Humans are intrinsically lazy. Too lazy to cook everyday? I guess I'll do all my cooking on Sunday so I have enough leftovers for the week. Too lazy to go to class? Well, I guess I can copy Albert's notes for the week.
We are always seeking the TL;DR of our daily routines.
If you look at the core definition of software, it is a series of instructions that directs a computer to perform specific tasks or operations (thanks Wikipedia!). You ask software to do these things because oftentimes it's easier and less time-consuming than if you do it yourself. The purpose of software is to promote your laziness.
Being lazy prevents us from spending time on repetitive, trivial things, so we can focus on the things we care about. You should be writing code in the same exact way.
Okay I get it, people are lazy, so what's the degree of separation between a programmer and an engineer, I still don't see it.
Anybody can program, but not everyone can engineer
If you are a person who codes regularly, most likely you can implement any product or problem thrown at you. Most programming problems have already been solved for you, so it's all about just writing it all up. So when presented with a problem, your natural instinct may be to say: "I know how to do that, let me put something together for you". Then you open up your favorite IDE and start typing away.
Never jump into writing code headfirst
Anybody can hack something together that works, in fact, that code can probably and will probably last a very long time. But the difficult part is how sustainable and adaptable it is to changes. These changes can include small tweaks, new product features, or an increase of 100x your active users.
For example, say you're implementing an Admin dashboard for your CMS tool. Say that on this dashboard, you have a bunch of buttons that can be clicked to redirect them to a different feature on the site. The "Pages" button will take them to the "page management" page, the "Users" button will take them to the page that allows them to edit users, etc. Sounds easy enough, you'll create a bunch of anchor tags that will define the page to redirect to. However, your Product Manager tells you that he wants to change the "Users" button to open a modal instead. Oh, and he wants another button called "Upload" that will create a full-screen overlay and let you upload the photos and it'll have a "close" button that removes it from the screen. One last thing, your PM also wants to AB test the "Users" button, so you'll still need to support both. Damn, now your original design doesn't really work as easily anymore.
A common reaction is to be afraid of rewriting code that worked or feeling wasteful by throwing away your previous work. So you may be inclined to write code around your original code. Then if a new request comes in, you write code around the code that you wrote that was around your original code. Then eventually you'll wind up in a spaghetti mess and regret all of your past decisions. But hey, since you're spending so much time getting it to work, you look extremely hard working!
From narrow to broad
One of the easiest mistakes you can make is to write code that only solves specifically one problem. Writing highly scalable, shareable, and reusable code is an art form. The science behind Software Engineering involves understanding the architecture of your system and then going from "narrow to broad". This might be opposite of the "start broad, go narrow" that you may be accustomed with.
When you write software with the customer in mind, there are always going to be variables and situations you may not account for, and that's okay. But, it is imperative that before you even write your first line of code, that you go broad and think about what might be an enhancement that you'll need to accommodate later.
However, you also don't want to be prey for over-engineering and factoring in too many variables (more on that in a future post). So build for today, but enable for tomorrow. That is major key to being lazy.
Sounds like a bunch of philosophical bullhonkey
You're probably right! Shoot, even I think the title "Software Engineer" is a misnomer. Engineering usually implies a concrete set of applied science, mathematics, and ingenuity to develop solutions to problems. Writing software is way too abstract and variable to be compared to traditional engineering.
Build for today, but enable for tomorrow.
Whether or not you actually believe in the notion that a Software Engineer is different from a Programmer, you should still be able to agree that everyone should strive to be lazy. It is our laziness that drives these amazing, sophisticated frameworks and technologies that enable us to do what matters most: delivering awesome products.
