Developer progression as a function of navigating complexity | Hacker News Reader

Developer progression as a function of navigating complexity

siddharthsarda.com

54 pointssid637640 comments

One of the most important lessons that I think it's difficult to really internalise, is that your job is far more about managing imperfections than it is about achieving perfection.

It's very hard to kill your darlings as a developer, you have the whole edifice of software engineering best practice right there on people's blogs, there are infinite frameworks, libraries and languages at your fingertips. An appreciation for what's theoretically possible is always useful, but I will hire, promote, and throw money at people who can deliver a 75% solution to a problem with 90% confidence. I will struggle with people who aim for 100% solutions that never materialise.

I don't think that I (as a younger programmer or if I'm honest even quite recently) would want to hear this, from my future self or anyone else, but I would have been happier accepting it early in my career.

I've been running up against this lately. It's a really hard lesson to learn for some of us. Code as a medium just caters way to much to perfectionist tendencies, to the point where you may not even come to see them as a problem.

I think it really does help to have an outlet where you can apply every last ounce of craftmanship to at least one project. That is very rarely something in a business context, but there is nothing stopping you having the most exclusive possible yak salon in our own time!

Yes I have found this to help!

Well said!

Hey, author here and I completely agree. One of the things that I meant to express in the article but couldn't was when as someone approaches a problem with an understanding of the context (business, people etc) they will be more likely to understand what's important, what's not and when good is good enough.

As a side note, I shared this article with Jessica as a draft and she shared it with her followers before I could add a few more things. Still my most successful post yet and comments such as these make me understand there is a lot of material for new blog posts.

Bought at least one book clicking through from this post, so thanks! It's a tough area, and something I'm stressing about a lot as I try and build as many career paths as possible for engineers at my current company.

My criteria for seniority is very simple:

Given clear requirements, can you be left alone for a reasonable amount of time and not come up with a monumental mess? If you can, you are a senior engineer.

And as a corollary, if you need constant supervision, you are not as senior as you think.

Another thing is, you have to lead other engineers. Not only you shouldn't need constant supervision, you are the supervisor in many cases.

How does this work on a team composed exclusively of senior engineers?

Where is the source of direction or vision for the project? Rarely is this task evenly divided.

There can be different sources of "direction" for the project: product, engineering and project management. The roles may overlap but the leaders that are good at those 3 things are rare.

The one with the most domain knowledge and technical excellence leads? thus Lead Senior Developer.

Those that sound like they know what they are doing, seem to make good decisions, appear to the manager as someone that will make them look good, and seem to be someone the manager can understand and trust will be promoted over someone with more domain knowledge and technical ability that doesn't have those other qualifications in some cases.

Don't assume a meritocracy, even if it had seemed that way initially, because managers change, and things often don't work like that.

Your job title/level/rank (“Principal Engineer”, “IC6”, ...) is what you’ve been deemed capable of (usually by doing it). But your role on a particular project is going to depend on what’s needed. Sometimes you’ll be the lead of the whole thing. Or the lead of a piece of it. Or just another contributor.

Some performance management systems are poorly designed to handle scenarios like this, admittedly.

Yeah agreed. Amazon expects everyone to follow their Leadership Principles but no team can succeed if everyone attempts to lead.

It depends on your role. If you are an individual contributor, you may not be expected to supervise other engineers or organize their work.

A senior engineer does not have to lead other engineers to be senior, only have the ability to do so if called upon.

And given _unclear_ requirements, you should be able to ask the right questions to make them clear. This is probably a harder barrier to overcome.

This is very much a hard barrier.

I find it even harder to produce clear requirements that don't precipitate such questions.

I guess it depends on your org but if you're required to do BA work, I find that the most challenging.

I humbly proffer that in order to produce clear requirements, it necessitates asking clarifying questions in the context of understanding what engineering effort is being requested.

And, perhaps, the most valued skill a senior developer acquires is enough business analysis (which I assume you reference as "BA work") ability such that the stakeholders feel comfortable in what they have conveyed is, in fact, what the development team will set out to deliver.

>And, perhaps, the most valued skill a senior developer acquires is enough business analysis (which I assume you reference as "BA work") ability such that the stakeholders feel comfortable in what they have conveyed is, in fact, what the development team will set out to deliver.

I could not agree with you more. Learning how to clearly communicate to stakeholders is an invaluable skill. One I have yet to master but deeply long to.

In a vacuum maybe, but one of the major challenges in any large technical organization is architectural alignment between different work streams. Meaning, that whatever you're doing for project A also has to be compatible for whatever is happening with completely different project B. Given how social cliques work, even if you are a senior engineer it's possible to find yourself going back to others over and over again just to make sure you're aligned with the major decision makers.

My employer has the following job titles in IT-

* Associate Engineer

* Engineer

* Senior Engineer

* Principal Engineer

* Solutions Engineer

* Architects, Sr Architects, Enterprise Architects

And my interpretation here for Senior is probably around Solutions Engineer, bordering on, if not completely in an Architect's domain. But the thousands of Principal Engineers and downwards all have a wide range of agency for implementing the four tiers demonstrated in the article.

Read TMMM and ask your manager to add the title next performance review. Seems to be all that's required these days.

Well, The Psychology of Computer Programming might help too…

What is TMMM?

I'm assuming The Miracle Man Month

Mythical Man-Month?

"Miracle" man month. Awesome.

I read one of the books suggested, team topologies, but I was shocked by some misinformation inside. Is this really a good read?

Becoming a SME (subject matter expert) in a certain technology (that would benefit the org) and then evangelizing that technology within the organization is a mark that I look for in a senior.

Care to elaborate? I would associate that to a beginner, and I'd expect a senior to simply advocate for whatever technology works best in each case (i.e., while the junior is focused on a single technology, the senior knows several and keeps in mind that they are just tools to solve business problems)

Becoming a SME in, let’s say Typescript (or for any statically typed language), for example easily takes 2-3 years unless you really excelled in type theory in college. Knowing the ins and outs of advanced types, generics, conditionals, etc and also having implemented these things to a degree where you can do it in your sleep.

No way a junior would be able to do that. Seniors have deep knowledge of the systems/technologies that they work in and are able to articulate that to more senior management on why using that particular thing is the way to go.

Obviously you want seniors to have more than just one (for both their sake and the organization) but it’s a mark that they’ve attained at least one technology that they’ve “leveled up” so to speak.

Downvotes for Typescript, that it doesn't take that long to master Typescript or something else? Flummoxed.

> evangelizing that technology within the organization

Ever heard of the term "architecture astronaut"?

> Your typical architecture astronaut will take a fact like “Napster is a peer-to-peer service for downloading music” and ignore everything but the architecture, thinking it’s interesting because it’s peer to peer, completely missing the point that it’s interesting because you can type the name of a song and listen to it right away.

I mean, I guess it's true that once one understands a certain problem area better than most peers, they will be able to find better alternative tech to solve the problem at hand. But, the other side of that coin is embracing or evangelizing a technology that is not appropriate to the problem (and thus possibly harmful to the business). "Hype driven development" and/or "resume driven development" are some instances of this.

BTW, I stumbled upon a relatively recent and relatively unknown development in CS (with potential real-world applications in parsing formal languages) some time ago, and evangelizing the technology is on my todo list since then. How to do this without seeming like an architecture astronaut? The fields of parsing and formal languages are actually quite unloved in both industry and academia in recent decades, so a more general question is also pertinent: how to get people interested in something that is widely considered boring, or even a solved problem? I guess starting a blog would be a good idea?

That's why I added "that would benefit the org". It takes a Senior to know hype from real applicable benefits.

That is an expensive thing to ask to a person (to be fair, depends on the depth you are asking), since that skill might be useless outside your organization, how do you manage this fact?

I’ve slowly been transitioning into a senior developer. It seems the closer I get, the more management/supervision I do, so the less time to work on my skills.

Your experience allows you to become a force multiplier by teaching/coaching others. Which requires learning that as a skill. Might not be a skill you want, but it’s a skill

Reply on news.ycombinator.com