The Joy of Software Engineering is in Creation (or “Thoughts on Burnout”)
If you are entering the field of software engineering for the first time, congratulations — though I am tempted to send you this article on how to assert dominance your first week, the truth is that it may be quite an adjustment. The main difference between coding in the industry and coding in school are that there are a lot more variables, both figuratively and literally. If you come from a college like the one I had, you will find that projects span a much longer period of time, and that maintaining code is a lot more important than it was in the past. If you come from a coding bootcamp, which I had not, you may find yourself at a serious disadvantage when your boss assigns you the task of drawing a Turing Machine with a number 2 pencil that determines whether or not an input string is of even length.
An Analogy for Production
If you have been coding for a few years and have no idea why software engineers might burn out, then…frankly…this may not be the post for you because you may be good. We had an intern like that. He was able to transfer his skill set and curiosity pretty well into the realm of production code, though he was not exactly a huge fan of legacy code.
I would argue that the main reasons for burnout are as follows:
- Software engineering at many companies is not “pure creation.” A big part of software engineering is maintaining existing code
- There is a lot of complexity in keeping things running, and there is a lot of code that becomes virtually unmaintainable over time
- Deadlines are hard to meet because completion dates are hard to predict
To elaborate on the last bullet point, here is an analogy dialogue section with Curt Corginia, professional mechanic. Curt can sympathize with his customer’s frustration
Customer: When will my car be ready? I need it operational in two weeks so that I can take a road trip to Vegas
Curt the Mechanic: It will take at least four
Customer: What? Haven’t you been working on this for seven weeks?
Curt the Mechanic: Have you thought of taking another car? A Honda, for example? It would get you there for about the same cost
Customer: It has to be a Toyota Corolla. No one in human history has ever driven to Vegas with a Toyota Corolla, they have always used either an airplane or a different kind of car
Curt the Mechanic: So I am making history?
Customer: Not really. My company’s key contract is just very particular about getting there on a Toyota Corolla. So why is it taking so long?
Curt the Mechanic: I had to update it to a 2021 Toyota Corolla
Customer: Why? The 2019 worked fine for me before, at least until the battery died
Curt the Mechanic: Terrorists have recently exploited a security flaw in the 2019 Toyota Corolla. The second you drove it off this lot, it would accelerate to 100 mph and then head toward the nearest cliff
Customer: Fair
Curt the Mechanic: Obviously your problem was with the battery, so I changed that, but even though the new battery works fine it had a serious incompatibility issue with your wheels
Customer: What? Why would a new and working battery make my wheels stop working? Was something wrong with them?
Curt the Mechanic: Not really, no. They swore it was backwards-compatible, but it’s not…that’s what I concluded after spending two days reading a 400-page guide on how wheels work
Customer: Didn’t you say you’ve been a professional mechanic for five years?
Curt the Mechanic: Yeah, but they made a ton of changes three days ago to how wheels work. Microsoft, which manufactures 70% of the world’s wheels, is currently in a massive legal battle with Google, which controls the world’s rubber
Customer: So what is wrong with my car?!
Curt the Mechanic: Well I’ve charged you for the upgrade and the battery and the wheels, but now I suspect the problem is with the windshield wipers. They are causing a catastrophic runtime exception, difficult to detect until you get above 50 mph, that will make your car explode. 40% of the time, fortunately, this problem will be detected immediately and it will not even start
Customer: FORGET IT! I will drive my car to another mechanic
Curt the Mechanic: Good luck with that
Software engineering, like most forms of engineering, consists of a bunch of different technologies that have to play nicely together. It may help to represent every major software component as a box, draw out the data flow, and keep that diagram on your whiteboard before you take part in your next major project. Long ago, the software components lived together in harmony. But everything changed when the Fire Nation attacked…
The Joy is in Creation
Find a random computer science student, and ask him or her what the most meaningful experience they had was. Chances are, it will be a project — regardless of whether this was pursued in the classroom, or outside of class.
Few will say that their most meaningful experience was studying for or taking a computer science exam, and that is the first issue. I would argue that coding interviews are analogous to exams, and that actual, on-the-job work is analogous to problem sets. We have an entire field of people who have to review computer science fundamentals (i.e. data structures and algorithms) to get jobs, then use a different set of skills (albeit with some overlap) to work on projects. These projects vary in size, scope, and complexity, but even the simplest production project I have ever seen is several orders of magnitude harder than the longest project I worked on in school.
The issue? Over time, these long-lasting projects — particularly if they are coupled with stressful deadlines — can lead to “code fatigue” and tunnel vision. The mind craves novelty, in this case meaning that people prefer to constantly learn, adapt, and see progress. Some projects involve working on a variety of technologies, continually learning about different parts of the stack, and rapidly acquiring new skills. Poorly managed projects consist of pouring through the same set of code, repeatedly using the same set of techniques, and working with people with the same narrow set of thinking. To an open-minded lead, new technology is a boon and its benefits should be weighed against its cons before it is accepted or discounted. To a close-minded lead, new technology is little more than unwelcome disruption, and such distractions should not be tolerated.
People are creative beings, and they want to explore, learn, and build. I think a lot can be said about how, in my experience, “program” projects consist of writing code that could last for years, and IRAD projects consist of writing code that could be scrapped in three months if the overall product fails to win a bidding war. Program projects are about working with a large system, patching it, and adding to it. IRAD projects are rapid development in new things, sometimes tangentially tied to existing code, built out incredibly quickly and maybe scrapped just as quickly.
Almost everyone I know prefers IRAD.
The Future is Hard to Predict
Say you are a college student tasked with writing a paper. You have an idea how long it takes you to write, you have a process down for obtaining good research material from your online college library in the form of peer-reviewed papers, and so you get to it. You read the main material again and jot down key ideas. You do research, flesh out your ideas, and form an outline. Then all you need is an all-nighter, a pot of coffee, and a bottle of liquor and you will wake up the next morning with an amazingly coherent A+ paper, five Tumblr posts you do not remember writing about your favorite TV series, and a trash can full of In-N-Out wrappers for a meal you do not remember ordering.
Okay, that was a bad example.
Say you were a college student tasked with completing a set of math problems. There are ten. They are independent and can mostly be thought of as modules, even if the knowledge gained from easier problems can be applied to harder ones. They vary quite a bit in difficulty, but each one you complete gives you a dopamine rush. You did it. You are 10% closer to completing your goal, and even if you did not touch the other nine you would still know one of them was done. These problems have an excellent testing system. You submit them online, you get more than one chance, and you immediately know if you did the problem correctly.
This is what coding should be like if you have a good testing environment and a set of clearly-defined goals, but I do not think it ever quite fits this description. Maybe you think you are 50% done, only to encounter a difficult bug part-way through — no one will ship code that works only 50% of the time unless they work at CORGICorporation. Maybe the bug is also a known issue caused by an open source framework you are using, and it would be much easier to wait for a fix than to dive into that code yourself.
You could say success is measurable by how much code you write (which Bill Gates sarcastically said is analogous to measuring planes by their weight), but you will not truly know if your work succeeded until it works with the rest of the system…and that goal could feel very far away.
CORGICorporation Invoice
Billable to: Our customer
Car: Toyota Corolla, 2019 (upgraded to 2021)
Service Performed: Battery replacement
Cost of Parts: Free. The battery was open source
First three weeks of labor: Before we could start working on your car, we had to buy a new car shop and put out the fires that it was still burning in
Next three weeks of labor: We had to replace the battery, 3D print an upgraded engine, replace the windshield wipers, replace all four wheels, and even then the thing would not start
Next three weeks of labor: No idea why your car no longer works but our money is on the seat cushions. Those things cause all kinds of problems
Next month of labor: OH MY GOD. THIS WAS SO DUMB. Your car was fixed two months ago, but we were trying to drive it in the park position. Wow! So silly! Okay, your car is good to go!!!111
Invoice: $50,000 for battery change
So What Can We Do About This?
- Relax. Take a little time off. Consider writing a blog post about software engineering, or your favorite Netflix series, or your thoughts on Dogecoin
- Consider doing a personal project. Flip the script on your work by emphasizing the learning over the end result, and not caring at all where you end up as long as you get to use new things in interesting ways
- Maybe see if you can change your perspective by relearning things from a different “angle.” For example, you can learn a lot about networks by playing CTF hacking challenges. You can learn a lot about emerging technologies by studying system design, and pretending to be more of a system designer and less of a programmer
- Do something else. Anything. Go for a run. Read a thriller novel. Pet a golden retriever
Thanks for reading. If you liked what you read, consider supporting us by visiting our car repair shop. We are known for our battery replacements.
