alt Hacker NewsAs a /senior/ developer I really dislike blanket statements. I've seen the same amount of failures caused by
> “Do we really need that?” > “What happens if we don’t do this?” > “Can we make do for now? Maybe come back to this later when it becomes more important?”
as with experimenters. Every system is different, every product is different. If I were building firmware for a CT scanner, my approach towards trying out new things would be different than a CRUD SaaS with 100 clients in a field that could benefit from a fresh perspective.
There are definitely ways to have eager/very open seniors drive systems into hard to get out corners. But then there are people that claim PHP5 is all you need.
Replies
Congrats on being the third top-level comment at this hour, and the first one who seems to have read more than just the headline.
A sort of survivor bias. A VP ordered to use elastic search, because it worked well at his company before. Turned out it worked well for us. Listen to the VP to make technical decisions. And use elastic search.
Agree. context matter. As a senior developer you need to understand complexity, risk, upsides and and downsides. Understand the business side. If you are a startup or a big company that is already a cash cow makes a difference when changing a core featrue of the product etc... context context context
I think this is contrarian, I found author's point clear in context. Obviously sometimes actions are warranted, but the balance today is skewed in making everything more complex than they needed.
This do not mean we don't develop new product and services, it just means when we do so, we find the path of least overall entropy, it also applies to operations and tech debt reduction.
premature optimization is root of all evil
I think you may be missing the message the OP is trying to communicate.
The qualities were highlighted because they can all lead to better stability.
I mean blanket statements are bad and you don't want to be the last company running on Java 6, but all the same, it's equally bad to be the guys using the latest javascript build pipeline that came out three months ago and is undocumented.
Was thinking the same thing, but then i re-read the section and noticed this:
> Yes, yes, of course this is simplistic.
It's an example, put to the extreme, to clearly communicate the ideas. As all things, the golden mean applies, as I understand the article argues for:
> the design of the 'Scale' version is influenced by what worked and what doesn’t work in the 'Speed' version of the system.
It's a tricky balance, and there's a nonlinearity in that it really depends on what technical risk you've already taken on. Like.. clever ideas are like children. A handful are fine, lovely even! But if you have more than you can adequately keep track of or properly nurture that's no good. So best to focus attention on the small number of clever ideas that actually matter for your business--the ones that differentiate you from all the other companies doing broadly the same thing as you.
I mean, sure, reduced complexity is great, but... what about performance?
[dead]
I came to say somethign simular actually.
> Ah, baby, this is my senior developer. The avoider, the reducer, the recycler. They want to avoid development as much as they can.
There are times when this is good, there are times when actively trying introduce an improvement is the best way forward. A good senior is able to recognise when those times are.