What are software engineering fundamentals?

The definition of a fundamental is a skill that will be useful anywhere you go. Fundamentals are really interesting as it's not binary either - Even among fundamentals, some are more broadly applicable than others (applying to your personal life as well!).

There's a lot of fundamentals that a software engineer can pick up, and I'll split the categories up into separate comments as there's simply so much to cover. Let's start with my favorite one:

Communication

This is by far the most important fundamental IMHO as it is literally useful in every single context, both inside and outside of work. Communication is a massive area that takes almost everyone a while to get good at, but to start, you should watch my entire Effective Communication series: Alex's Guide To Effective Communication

Communication is also connected to many other "sub-fundamentals":

• Building relationships - In particular, your relationship with your manager is important from Day 1 of your career, even if you start off as an intern (for advice here, watch this: Having The Proper Mentality For Manager 1 on 1s). Once you start approaching mid-level, you'll need to build strong relationships with your teammates as well. And once you get to senior/staff, you'll need to build relationships outside of your immediate team!
• Effective meeting presence - This accounts for both participating in meetings and running them. Meetings are a staple of almost every software engineer's life, and they only become more important as you become more senior. If you're just starting off, I recommend this discussion on how to participate more in meetings: "I struggle to come up with things that add value to a meeting - What do I say?"
• Leadership - Leadership is largely an exercise in, well, everything mentioned above and the sub-fundamentals after as well. To learn more about leadership, I recommend this video about my Meta -> Robinhood transition: [Case Study] Becoming A Tech Lead Again In Just 1 Month After Joining Robinhood From Meta
• Mentorship - This is one of the most powerful ways to have multiplicative impact and is one of the core ways a high-performing senior/staff (or higher) engineer can scale themselves in a healthy way. Mentors need to be able to communicate concepts clearly and in an easy-to-understand way to teach more efficiently. They also need to be able to share honest feedback in an empathetic way to avoid hurting people's feeling. To learn about all this, check out mentorship deep-dive: [Case Study] Mentoring Junior SWEs [E3] to Senior [E5] In Just 2.5 Years At Meta

Productivity

Similar to communication, this can also be applied outside of work. The math is simple: If you are able to get more work done per unit of time than others, you are in a great position. To get better at this, I recommend this masterclass: [Masterclass] How To Manage Your Time Optimally In Tech And Achieve More Results

Here are some "sub-fundamentals":

• Having a strong flow state - The idea is that when you have a long uninterrupted period of time, you are exponentially faster. This is the state I got myself into in my later days at Meta and at Robinhood: ~75% of the code I wrote came on no-meeting Wednesdays.
• Being good at context switching - When your calendar is peppered with meetings (i.e. most senior+ engineers), it's very powerful if you're able to get something concrete done in those 15-30 minute blocks. Here's my advice on how to get better at this: "How to improve at multi tasking at work?"
• Meeting management - This boils down to 2 things: Not going to meetings that aren't very useful to you and concentrating similar meetings on certain days to give you more focus blocks. For the first part, I'm surprised nobody has asked about how to evaluate the usefulness of a meeting yet, so I don't have a direct resource handy unfortunately. To substitute, I recommend this video: The #1 Thing To Remember With Meetings

Quality

This one is more specific to software engineering, and I recommend this Q&A from a Meta engineer as a starter resource to learn more about it: "For self-taught developers - How to build my own knowledge system during work?"

Here's the "sub-fundamentals" for it:

• Having a nose for edge-cases - I owe a huge amount of my career success to this: One of the best examples is when my attention to detail allowed me to catch a massive bug at Instagram, which I walk through here: [Case Study] Solving A Multi-Million $$ Instagram Bug. Fixing this bug saved the company $1M+ per year, and it was a large part of my promotion to E5 (senior engineer). There are many ways to build up this sense including talking to your friendly local QA engineer, dogfooding your own product, taking some time to think proactively before starting a task but my main piece of advice is to not be afraid and test diligently outside of the happy flow. I have seen so many developers write code, deploy it, timidly test only the happy flow, and submit the PR - The code's going to blow up eventually; it's not healthy to ignore the messier cases.
• Understanding users through data - This is something that I really learned at Meta, and I'm glad I did so. Even early-stage startups (like Taro!) have analytics; it's the main way to understand whether your users love your product at scale. And once you understand your users, you can truly make the product better for them. To learn more about this, I recommend this Q&A around how to become an analytics lead: "I want to become the "data guy" in my company - How can I do that?"

I will add one more

Compassion

The ability to Sympathize with others and understand where they are coming from becomes increasingly important as you progress in your career

• Use compassion to understand the need of your teammates

  • Know them not just in work settings but take your time to understand their interest, passion and career goals.
  • This gives you an edge when collaborating with them since you know "what drives them".

• Use compassion to understand the priorities of your managers/directors

  • Managers (especially frontline ones) have a hard job. They are basically sitting in meetings and have to deal with all the distractions. Sympathize with that and see how you can make their jobs easier.
  • This gives you an edge to really understand what are the most important things for you to deliver.

• Use compassion to understand the priorities of other teams

  • Things that are important to you and your team might not be a priority for others. Dig in and understand what their priorities are and see how you might be able to help
  • This gives you an edge to achieve alignment when there is a conflict.

I've been thinking about this myself lately, but more so from the perspective of what I admire about strong SWEs. In addition to the very important skills the answers so far have already provided, here are some more technical pieces that I think strong SWEs often demonstrate.

• A strong knowledge of the fundamentals of computer science. Strong SWEs seem to be able to quickly pick up on the inner workings of the abstractions they are using when they need to. Often times, this requires some level of computer science understanding. They know, at the foundational level, how computers work, how languages work, some general frameworks and patterns, and how the internet works. This should most certainly include data structures and algorithms because computers are built completely off of these concepts. I suppose this might be why DSA is the interview standard, although it is true that the majority of work SWEs do on a daily basis don't require it. This type of knowledge is what allows a SWE to reason from first principles.
• A working knowledge of the full software lifecycle. Being able to quickly bring what a SWE is expected to bring at each point in the software lifecycle. For example, during ideation phase, this means being able to bring technical solutions and constraints to the table, including tradeoffs for different paths, and communicating it well. For another example, at the test stage, being able to draft up a test plan that will ensure consistent results even after the current release.
• They write forward and backwards compatible software. When strong SWEs release something into production, they're confident they're not breaking the existing experience, and they know they'll be able to continue building on top of the software they just shipped. A part of this is related to good habits surrounding flagging new features and bug fixes.
• They know how their software is doing. At any point in time, a strong SWE would be able to quickly figure out how their software is doing in the real world. This means that they've strategically placed logs in their software and have a place to monitor them. They are also monitoring the health of the resources that are running to serve them. For devices, this means things like battery usage and device thermals. For servers, this means similar things like CPU and memory usage.
• They have a classical understanding of privacy and security. Violating privacy is one of the sins of our generation in software. Knowing how to ethically manage the end user's data and know at what points of a system security may be a concern is a skill any SWE should have. A strong SWE understands the classic strategies to protect the user's privacy and security and know when they need to ask for more specialized help.
• Automation and abstraction. The "lazier" a SWE is, the better they seem to be, mostly because they quickly recognize when something can be automated or abstracted. Then they appropriately invest in the ones that'll give them high returns.

Some of these skills I'm actually missing myself even to this day, and I plan to dive into them over the next couple of years.

In terms of how to pick these skills up, most of these should come with the job and being promoted from entry-level to senior as long as your company has good SWE practices. The two that are a little harder to get just from getting to senior alone are "Automation" and the "Fundamentals of Computer Science". Automation comes with your own observations of things that are repetitive and can increase the velocity of you or your teams output. Learning computer science requires school or the combination of self-study and side projects that help you gain those concepts.