I’m a senior engineer (web full-stack) at a bank. I’ve been doing this for about 5 years.
When I write code, I find it similar to authoring a book or even writing a poem. I love trying to write code that reads really well, has beautifully designed boundaries between dependencies, great structure and so on. I also find that I write code with a big focus on making it a joy to work with for developers that touch it later on.
I struggle with the emphasis on collaboration and quick iteration approach in this field. “Co-authoring a book” with 6 other “authors” in two week chunks just seems crazy to me. And what I’ve seen that passes as shippable code is also crazy to me – but hey, “it works”.
I also have never been a guy that gets overly excited about using technology to solve problems or using software to satisfy business needs. I really just like writing code, setting up development environments or CI/CD pipelines, cloud infrastructure or whatever…just for those things themselves. (Again it’s like an art form to me. And I really really like reading other’s well thought out code and appreciate for just that rather than the use-case or problem that the code is actually solving)
Anyone else out there like me? (Not arguing the merits one way or the other…just curious if I’m a weirdo)
You’ve found one of my favorite topics to stir up great developers thoughts on! Please pardon my wall of text:
Great authors have as much, or more editor/co-author input as great developers.
The idea that any developer can sit alone, without feedback, and write thoughtful, elegant, easily maintained code is ego - not reality.
As a manager, I have found that developers allowed to work solo create code that is simply thrown away when they leave the team.
Exceptions may exist, but I haven’t encounted even one in 20 years and 5 teams.
My developers who wish to work this way assure me that their process accounts for this problem, and it’ll be fine. It has not been fine, and I no longer entertain the conversation.
As the person accountable to ensure the code base my team produces maintaints it’s value, I mandate that all developers who work for me put 100% of their code through peer review.
Our goal isn’t just new features, it’s correct maintainable features. The only way I have been able to achieve that is for the team manager (me) to prioritize peer code review over new feature releases.
That said, I’m very sympathetic that the vast majority of teams get this last bit wrong - they fail to prioritize review over new features - and make the whole thing a huge waste of time.
Hey, don’t be discouraged.
You are a treasure and rare. There are places for folks like you. I hope you can find one where the culture fits you and knows your value.
Until then. You can try to change the culture. But if that’s possible depends on more than I know for your context.
With small teams it’s easier. Demonstrate competence, gain trust of everyone around you, then sell a better tomorrow where … Stuff just works. Faster velocity, more features, fewer bugs, etc.
This is a very valued message in some places, and totally not in others.
I have a feeling that infrastructure/platform/core teams – those making tools for other engs – are probably more naturally aligned to quality and lower defect rates. That may be a direction for you if you aren’t sure where to start aiming towards.
Yeah, this is me. Coming up on two decades in game dev, and I’ve always cared way more about building things that are genuinely robust and also make sense to humans, but everyone just wants “fast and cheap”, thinks documentation is a waste of time (“you can just talk to people”), doesn’t understand “tech debt” as a concept at all, and refuses to prioritize tools work because “it’s not player-facing”.
All software is rushed software.
