Professional Software Engineer Vs School - A lot of "No's"

So you’ve finally gotten through discrete math, functional programming, and operating systems, grinded on Leetcode for months, and have a job offer to show for it!  You likely came into college knowing nothing about how to code, and after countless sleepless nights of struggling, find yourself in a position where you finally feel confident about your skills.

So, what is life like as a professional software engineer?

Funnily enough, the reason that our new job title is “software engineer”, and not “computer scientist”, is because there is much to this profession beyond the scope of what we learned in school.  Our job is to manage, build, and maintain software, and to repeat one of the first quotes that I heard from an extremely seasoned engineer at my company, “code is not an asset, it’s a liability”.  Things can and will break, and when they do it can have an extremely large downside on your business.  Think about how costly a user data breach would be for Facebook right now!  Only by building up our programming skills, but also a vast suite of soft skills such as communication, presentation, and networking, can we navigate the interesting landscape that we call a business.

With this in mind, I aim to cover some of the main areas in which being a software engineer diverges from being a computer science student.  The earlier in your career that you are able to fully recognize and account for these differences, the sooner that you can go from a simple low level engineer “who just writes code” to a more senior actor that is able to push the direction of both your team and other teams in your organization.

Pushing back as a professional software engineer

The first main difference that I’d like to highlight is “pushing back”.  In college, when a teacher provides you with an assignment, you have to do it.  Well, maybe you don’t “have to”, but there’s a very clear path to success, and it’s by implementing projects exactly as guided by your superiors.  On the other hand, exclusively looking to your more senior engineers or stakeholders for direction on what to do or how to do it is a recipe for disaster.

Primarily, stakeholders are often wrong.  Especially when the clients of your product are not intimately familiar with its technical implementation (which is often the case), they may suggest ideas that would negatively impact it.  For example, a feature which they think is easy to implement which would provide them nominal value, when in reality it would take months to build given the existing system architecture.  In these situations, you can and should “push back”.

Be respectful, but calmly present your reasoning for why their feature is challenging to implement - and ideally offer some sort of middle ground or compromise whereby you meet their most important requirements while also protecting developer resources.  Obviously, this actually requires knowing the product - and is a reason that it is generally the more experienced engineers who will provide friction against stakeholders.  Just saying “I don’t feel like it” isn’t going to fly (darn!).  That being said, doing so is a key skill to managing your time and ensuring that you don’t go down a rabbit hole of work due to an uneducated request.

The same concept applies to senior engineers on your team.  As you continue to work, you will become a subject matter expert in certain areas that you’ve spent significant amounts of time working on.  At first, your older engineers will seem infallible and omnipotent, but the reality is that they’re humans, and they make mistakes. If they tell you to do something or that something works a certain way, make sure to do some due diligence and not just accept what they say as truth. Assuming that your senior engineers are always correct is a great way to lead yourself down a path that wastes a lot of time, and ultimately the only person responsible for managing your working hours is you.

Finally, in a similar vein, keep in mind that people can and will push back against you also.  There will be many times throughout the course of your career when you work in an area that you’re less familiar with, and the engineer largely responsible for that codebase will try to scrap your idea that you need to get implemented.  In this case, the burden is on you to be able to prove your case: explain why the feature is needed, the impact of it, the expected timetable, and the risks associated (what might this break?).

Ultimately, being able to wield your communication skills to actually convince other people of the value of your work is the most powerful thing that you can have in a massive company where most people are extremely unfamiliar with the work of others.  In school, there’s no need to convince anybody of anything, you have an assignment that you’re told to complete, and you do it - nobody is trying to stop you.  In a company, you need to be your own advocate, and convince others of the value of your features, both so that you can get the green light to actually implement them, and also be evaluated relative to their impact during performance reviews.

Growth as a professional software engineer

Everybody acts as if software engineering and big tech companies are extremely meritocratic - but the truth is that building and maintaining relationships at work is crucial for getting things done.  When projects are only approved if they “add value”, getting others to believe that you’re a competent engineer, and having a pre-existing good relationship with them (via team bonding events, coffee chats, team lunches) provides great utility when navigating these interactions which many like to dub “politics”.  Your job as a software engineer isn’t to sit there staring at four different monitors and push code reviews - there’s a reason why senior engineers often spend much of their day in meetings.  They have to navigate a complex social situation of getting projects accomplished without stepping on anybody’s toes.  As you find yourself moving up the corporate ladder, you’ll notice that less of your day becomes about writing actual code (which is almost considered trivial) and more of your work goes into designing features and aligning both the stakeholders and engineers that they impact.

School is hard - much harder (from a pure academic standpoint) than software engineering in my humble opinion.  But at the same time, software engineering is extremely complex.  The only type of conflicts you’ll likely have to deal with when working in a group at school are merge conflicts.  This is not the case in an actual company.  To summarize, your job as a software engineer is to try and solve the following optimization problem: maximize developer resources, minimize liabilities, and provide maximum benefit to your stakeholders.  To do this, you need to truly understand what your stakeholder is looking for, and learn to navigate in a “sea of no’s”.

Thanks for reading!  If you enjoyed this blog post, please check out my YouTube channel for both technical and non-technical content so that you can succeed in the field of software engineering!

Jordan is a software engineer who has interned and worked full time at multiple FAANG companies, he now works in high frequency trading.