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)
deleted by creator
Side note: as a 20 year vet, can you comment on my theory that I’m going to age out of software engineering? How did you make it 20 years? (Real question)
deleted by creator
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.
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.
I’ve been in the industry now for just over 10 years. I have a particularly potent cocktail of ADHD+autism that has resulted in me being very similar to your description - If it were up to me, I would take the extra time to make things incredibly nice to work with and with cleanly-defined dependency boundaries every time. I can write code all day and enjoy every second of it, often to the point where I work too much. Sometimes I’ll spend time after the “official” end of the work day to just clean things up and refactor so that things feel cleaner.
The unfortunate truth, though, is that the industry at large doesn’t make it super easy to find companies that appreciate folks who prefer to take it slow and get it right. I’ve hated the “ship it or shut it” culture for a long time, as it means I don’t get to take the time crafting the solution I want to craft, and instead I have to push what sells. It ultimately results in a best-effort that works! … until it doesn’t. It results in harder-to-troubleshoot bugs, code that is harder to read, and a frustrating amount of revisiting old code that was written fast and loose in the name of “time savings,” when the time saved is just spent fixing the problems created by “moving fast”.
The owner of the (very small) company I work for often says “There are two kinds of code: Perfect code and written code. One of those makes us money.” and I’ve spent a long time hoping we’d reach a point where the written code makes enough money that we can slow down and write better code. We’ve not reached that point yet, but it’s the whole reason I have side projects: So there are things I can spend that extra time on to get things right.
To answer your question: Yep! You’re a weirdo, but me too. And that is absolutely not a bad thing.
I left software engineering as of 15 years ago for this exact reason.
I learned how to code, it was magic, it was grand. Then I went to school for it, and was a little surprised that most people there didn’t feel like I did about it. Then I got out and started working at writing code, and it was dogshit. I found a place that was kind of okay, stayed there for a while, and finally bailed and decided to do something totally different.
I’m actually trying to get back into it now (right at the perfect time 🥲) but yes I’m sort of steeling myself for the sad reality of what I might be walking into. For what it’s worth, if you can get it, good server sysadmin roles are sometimes pleasing to that same sensibility of being able to make beautiful stuff and sit back and let it run, without the necessity to crank out dubious code that hurts your soul.
deleted by creator
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.
