Early Software Engineering — Lessons they Never Taught Me in School
I have been an “official” software engineer for about three years now. Like many milestones in my life, this one has been met by personal questions like, “Why am I not better at this yet?”, “How do I get better at this?”, and “Why am I writing a blog post about how to get better at this when I am not better at this yet?” As you can probably tell, I do not consider myself an authority on any particular aspect of software engineering…but maybe it’s better that way. I know that I have a long way to go and a lot of things to learn, I know that I have tons of opportunities for improvement, and I hope that the people who read this blog can share in my journey.
There are a million and one articles about software engineering on Medium, many of which explain how to get started in the field, how to get over Imposter Syndrome, and how to land a first job. I find it a little more difficult to find blog posts about how to continue in the software engineering field, how to refine your skill set after you have settled down, and how to remain and your first job and/or pursue a second position. Unlike the style of many similar articles, this one will be open-ended: It will not pretend to have single, succinct answers, but it will make broad strokes.
I don’t know a lot, but I do think I know a hell of a lot more than what I did when I walked the stage and got my degree.
Lesson 1: Most of what you do involves understanding existing code, not just producing new code
A friend: What’s the main difference between coding in college, and coding in the field?
Me: There are way more variables, both literally and figuratively
My coworkers and I have been trying to find ways to describe legacy code. It’s old. It’s worked for a long time. We have the budget to maintain it, but we don’t have the budget to rewrite it. It takes a really long time to make it do new things. It takes a really long time to figure out why it even does certain things.
When you start, you are going to be asked to understand existing code. It might be legacy. There might be thousands and thousands of lines of it.
So what do you do?
There are a few different strategies you can take. I happen to work at a company that almost exclusively uses C++ code, code that can be described as esoteric at best and absolutely cryptic at worst. But I think that the strategy, regardless of language and tool suite, actually mostly boils down to the same key elements:
Start with the main thread, figure out how the data flows, and then incrementally figure out how to modify it. A coding sprint, in the most typical case, will involve you taking existing code and making it achieve some new feature. I find the thing analogous to seeing if you, as a new mayor, can understand a city well enough to take control of it and change it before your time runs out.
Documentation obviously helps. Sequence diagrams can be hugely helpful, and if you don’t know what it is then I highly recommend that you learn about it. Some strategies, like reading files linearly/top-to-bottom after you have a solid grasp of how things work, are still strategies I am thinking through and experimenting with. There is no easy way to get good at understanding completely new code, but it is a skill in and of itself.
People are your best resource, kind of like how the writers of a TV adaptation of Game of Thrones had the easiest time when written source material existed and the author was right there to explain why certain things happened and how to best make new adaptations.
Lesson 2: Soft skills are extremely important, especially when you first start out
I have met more than one software engineer who complained that the people who get promoted most quickly are not the ones with the best coding ability, but the ones who have the best soft skills. Many times, I catch myself falling into that category of critic.
But there really is something to be said about soft skills. A person with good soft skills may not just be able to complete his/her work in reasonable time, but also help mentor people along the way. A person with good soft skills may not just have confidence in ability, but inspire others to have confidence in their abilities as well. Soft skills make a software engineer collaborative, diplomatic, and mature. Soft skills are the reason one software engineer on my previous team was quickly promoted, while an arguably better software engineer with a poisonous attitude was sent packing.
In college, a lot of these soft skills are kind of overshadowed by sheer technical ability. Can you explain how the thing works? Can you effectively talk through what the requirements are, what process you will do, and what kind of challenges you are currently facing? In the event that you will be unable to meet a deadline, do you have the spine to suggest that you may need more time and the integrity to bring attention to things that may be problematic? Software engineering in the field is a complex network of interactions, a kind of continuous series of negotiations, compromises, and potential conflicts to resolve. If you can be calm under pressure, intelligently make trade-offs when trade-offs are necessary, and address your concerns and disagreements with people without turning to unnecessary confrontation or passive aggression, then you are setting yourself up for success in the long-term.
But if you are indifferent to the feelings of others or hostile and arrogant, then you are setting yourself up for failure in the long-term…even if your technical abilities are impressive.
Lesson 3: You need to know when to ask questions
I was the WORST at this in school. I don’t know if I would say I regret it, since this was all a long learning experience, but I would ask questions like crazy. I earned something of a negative reputation among professors.
I don’t think you will meet many instructors or technical leaders who say that it is a bad thing to ask a lot of questions, but when you have a student to uses your online forum to ask about how to do question 1 of 10, then waits ten minutes and posts ANOTHER time to ask about how to do question 2 of 10, he deserves to be made fun of at least a little bit.
Why was I like this? Simple: Speed. If you have a problem set with ten preparatory questions, it’s a little faster to ask for a response on an internal class forum than it is to use Google. I wish I could have gone back in time, slapped myself, and explained in simple terms why this is the wrong attitude (HINT: The best way to learn is not to have someone immediately tell you the answer to a question you just finished reading).
In the actual field, the consequences are kind of compounded. If you ask a more knowledgeable person a question, you are taking a certain amount of that person’s time. Sometimes, this is completely justified, and it would actually be stupid not to ask. Even if the person seems annoyed, you are ultimately giving your team what it really wants in the long-run: You are making yourself more independent, so even if you annoy people with questions now, later on you will be capable on your own.
So where you draw the line? Personally, I started taking on a practice where when I have a question about something, I literally type it out and spend a little time thinking about it. I write down what I will look up, what the answer probably is by common sense, and what I will probably ask if I have no other option. Sometimes I have to ask, but sometimes I don’t. Sometimes the very act of phrasing a question gives me an idea what the answer is, so by writing it out first I don’t have to actually ask.
Lesson 4: Attitude matters
This point has already been touched on above, but it deserves to be repeated.
Lesson 5: Not everything is about you
In fact, in a large company very little that goes on from one day to the next is completely related to you. What matters is what the team does. Teams are made of smaller teams. The experience can be intimidating at first, feeling like you’re just one unit in an insanely massive bureaucracy…but there’s also something liberating about it.
You don’t have to feel like the world rests on your shoulders. Your teammates exist to support people like you, people who are their teammates. One consequence of this, though, is something I think I’ve known for a long time but still need to work on:
The absolute best way to become a better programmer is by doing personal projects.
You get to make all the decisions. You don’t have certain major parts of your project outsourced to subject matter experts. You get to see the whole thing, start to finish, and you get to make all the calls regarding design, what to use, and so on. On work projects, the main goal is for you to contribute as much as possible to your company. On personal projects, the goal is whatever you want it to be…even if that goal is to not submit a single thing anywhere, and to simply learn a lot about something you find interesting.
Lesson 6: There really is a great software engineering community, you just need to know where to look
You might not like everyone you meet in the field. That’s okay. You will probably meet some people who are insensitive, some people who are overly sensitive, some people who are arrogant…and in the process, you are going to meet tons and tons of great people who love problem-solving and want the world to be a better place because of what they gave it.
I didn’t like a lot of the software engineering community at first, simply because of some negative stereotypes I acquired from Hollywood and/or possibly 4Chan, but then I found a few people online that I really liked. Here are just a few:
https://www.youtube.com/user/VSympathyV/featured
Happy coding.
