4 ms·

As a junior with the regular high aspirations for career growth to Staff engineer/leadership, am I doing myself a disservice by orienting myself early in my ca

As a junior with the regular high aspirations for career growth to Staff engineer/leadership, am I doing myself a disservice by orienting myself early in my career around "Systems thinking" (NFRs, requirements analysis, testing, observability etc as the article discusses), instead of focusing on the technical "code quality, best practises and cutting edge qualities"?

CiPHPerCoder 4y ago
Not really. Systems thinking is broader in scope and responsibility. You're going to have to cross the rubicon eventually (unless all the software projects that hire you fail gloriously before they achieve any significant scale, I guess). Code quality, best practices, etc. involve the same values and priorities as systems thinking, but is scaled down to a bus factor of 1. (i.e. the code you, personally, write or review). Going beyond n=1 requires building mechanisms and guard-rails to prevent a failure of the individual level from affecting the larger system in a bad way. Thinking about it early won't significantly kneecap you from writing good code. If it interests you, go for it. The only reason you might not want to do so is if it doesn't interest you right now. You'll likely get there one day, once a project you care about scales up enough.
hosh 4y ago
They synergize together. As an example, what's beyond code quality is writing library code where doing the right thing is easier, and is aligned with the system. If, for example, one uses a design pattern whose anti-pattern is misaligned with the overall system, then it is easy to do the right thing locally and the wrong thing systemically. As another example, the "best practices" are actually sound engineering principles applied specifically and locally. In a different architecture, with a different constraint and use-case, how those principles applied may sometimes look different than what "best practice" says, but not so strange if you understand the engineering principle underlying the "best practice". Lastly, I would say, "systems thinking" always includes people: the people writing the code, the people making sure the infrastructure is running, the people using the system as end-users, the people supporting the users, the people running the business, the people paying the business, the people depending on the technology. Incorporating that means dipping into a product perspectives where people talk about things like, ux, or "job to be done", or "lived experience" rather than "requirements analysis" or "observability".
0xB31B1B 4y ago
My biggest suggestion to anyone looking down this path is, in addition to your normal SWE responsibilities, really understand production engineering concepts (testing, reliability, alerting, monitoring, running an on call rotation, capacity planning, etc). At a smaller company being the one SWE who can do these things in addition to their normal job roles is probably the fastest skill set to develop to unlock staff promo. It's less important to be the quickest arcane bug solver and more important to be the person who can see all of the problems with a system and work independently fixing them.

CiPHPerCoder 4y ago

Not really. Systems thinking is broader in scope and responsibility. You're going to have to cross the rubicon eventually (unless all the software projects that hire you fail gloriously before they achieve any significant scale, I guess). Code quality, best practices, etc. involve the same values and priorities as systems thinking, but is scaled down to a bus factor of 1. (i.e. the code you, personally, write or review). Going beyond n=1 requires building mechanisms and guard-rails to prevent a failure of the individual level from affecting the larger system in a bad way. Thinking about it early won't significantly kneecap you from writing good code. If it interests you, go for it. The only reason you might not want to do so is if it doesn't interest you right now. You'll likely get there one day, once a project you care about scales up enough.

hosh 4y ago

They synergize together. As an example, what's beyond code quality is writing library code where doing the right thing is easier, and is aligned with the system. If, for example, one uses a design pattern whose anti-pattern is misaligned with the overall system, then it is easy to do the right thing locally and the wrong thing systemically. As another example, the "best practices" are actually sound engineering principles applied specifically and locally. In a different architecture, with a different constraint and use-case, how those principles applied may sometimes look different than what "best practice" says, but not so strange if you understand the engineering principle underlying the "best practice". Lastly, I would say, "systems thinking" always includes people: the people writing the code, the people making sure the infrastructure is running, the people using the system as end-users, the people supporting the users, the people running the business, the people paying the business, the people depending on the technology. Incorporating that means dipping into a product perspectives where people talk about things like, ux, or "job to be done", or "lived experience" rather than "requirements analysis" or "observability".

0xB31B1B 4y ago

My biggest suggestion to anyone looking down this path is, in addition to your normal SWE responsibilities, really understand production engineering concepts (testing, reliability, alerting, monitoring, running an on call rotation, capacity planning, etc). At a smaller company being the one SWE who can do these things in addition to their normal job roles is probably the fastest skill set to develop to unlock staff promo. It's less important to be the quickest arcane bug solver and more important to be the person who can see all of the problems with a system and work independently fixing them.