
Ask HN: Disklike of modern trends == Becoming a relic? - ThrowAwayOG
I have been in IT and software roles for 3 decades, yet nowhere near retirement. I still get a lot of stuff done (solo and teams), but only feel productive when pragmatic approaches are taken. I often find a carefully written but quick prototype is valuable while laying the foundation for a permanent system to be built if needed. Problem is, most of my company insists on first developing fully fledged platforms that attempt to solve years of future assumptions, while the business waits and engineers work excessive hours.<p>If I suggest a simpler prototype approach, incorporating internal customer feedback, with a second long term cycle of engineering, the response from peers and management borders on disdain or contempt. I am a team lead and get this response from all angles.<p>I’m no tech stick in the mud. Where scripting and RDBMS worked for 20 years, I incorporate “new things” where needed: Go for speed, Spark and S3 where vertical systems don’t scale; Rust when performance of a non-GC language is needed.<p>Conflict occurs when I resist over engineering: _Everything_ in a container; Kubernetes by default, as in 10 node clusters (am aware of its utility in much larger deployments);  Clever code that will be extra work for future contributors to grok. Anywhere resume driven development appears to be creeping in.<p>I believe one of the responsibilities of management (and team leads) is to reign in architecture astronauts, but I  rarely see it and am discouraged from doing so, in some cases due to fear of upsetting the “10X engineers” [1].<p>I have seen this across 4 companies in 15 years, with increasing severity. Is “build to minimum requirements” no longer appropriate? Have I selected roles poorly, and my experience is abnormal? Do people still just get stuff done both in the short and long term [2]?<p>Or is it time to hang up my spurs and take up golf?
======
ThrowawayR2
If you're a relic then I'm one too.

The trends I blame are 1) computing power has become so crazy cheap these days
that nobody cares about overengineering or even doing engineering at all, 2)
lower quality of software developers; back in the day, it took deep interest
(since software wasn't as lucrative a job) and considerable skill (since
computers were very limited) to enter the software industry and succeed, and
3) fetishization of the latest software development fads. These trends are too
large to successfully be bucked but, hey, there are worse places to be than
being paid well to watch other people flush their own money down the drain.

~~~
ThrowAwayOG
> fetishization of the latest software development fads

Fetisization is a term I will likely be using more now.

> watch other people flush their own money down the drain

I'm not concerned with a lack of cost efficiency, unless my team's job (and
income) security is risked due to a failure to deliver in a timely fashion.

I also tire of arguing about why I won't deploy a 4 node K8S cluster and am
therefore not a team player.

> there are worse places to be than being paid well

Definitely a good counter point to the positive.

------
ThrowAwayOG
[1] For context I put zero belief into the idea of the 10X engineer or full-
stack developer. Most real world projects are addressed by a _team_ of people
that must work in concert. The idea that one of them is superior to the rest
is toxic - and most often nothing more than an overgrown ego.

[2] “Get stuff done” != “Break shit and move fast”. That is an entirely
different problem. I’m not referring to disrupting industries or putting
people in space. I’m referring to typical, somewhat mundane business
technology.

------
anonsivalley652
It seems to lowly-old me that you come-across as possibly tired of exceeding
your BS/reward ratio.

If so, a vacation/sabbatical could be needed if it's a temporary thing. If
it's permanent, finding a promising startup with a defensible business model
to be a first-round employee might be a better option. They skew towards
hiring A-players (not always, but usually).

If staying for some time: Popularity != engineering soundness. Fools and
novices are allergic to simple, especially if they've never built solid
anything at scale or worry about work being taken from them. It doesn't sound
a collaborative/consensus environment either, maybe a toxic, religious,
adversarial one containing outsized egos who want _their_ solutions advanced
because it's job security for them, and anything else gets in _their_ way. You
could try asking them what are their specific objection(s) to seek their
honest feedback. Using self-deprecation can be helpful too.

Personally, I don't use Go anymore for the past 2-3 years. I prefer Rust for
speed, Haskell for generality and Crystal for rapid prototyping. I'll use
anything to get a job done, because real customer problems and real solutions
are rarely perfectly-crated masterpieces in your favorite tech stack.

IMHO, Go got too popular, fashionable and full of needy noobs who dragged the
ecosystem down. (Ironically, I remember telling a head-hunter in about 2011 he
was dead wrong and to never call again since he arrogantly proclaimed Go was
going "nowhere.") I hate K8s and systemd because they're overkill, "emperor's
new clothes" amoeba-ware that are poorly-conceived, poorly-executed and of
marginal benefit compared to what they replaced. It's important that "new"
projects crammed down our throats because of celebrity and techno-
fashionabilism not be easily compared to today's latest flavor Javascript
library. Only after exhausting attempts to fix deficiencies in existing
solutions, then deeply consider/seek feedback about the impacts, UX, behavior
and interop of proposal through project-based RFCs.

That's my 2c from ~25 years being a code monkey punching buttons on glowing
boxes; and maybe I'll accidentally write Shakespeare one of these days. ;-)

~~~
ThrowAwayOG
> It seems to lowly-old me that you come-across as possibly tired of exceeding
> your BS/reward ratio.

I think you nailed it.

> You could try asking them what are their specific objection(s) to seek their
> honest feedback.

"It won't support our needs in 1-5 years" (The projects in question are not
supporting our needs for the next 0-12 months).

> Using self-deprecation can be helpful too.

Agreed, but in the current case it seems to embolden those who do not wish to
discuss alternatives.

Which is another problem I neglected in my post: The mere suggestion of
alternative approaches threatens our 10X egos, and communications tend to
degrade at that point.

Sometimes the solution - for the mental health of all involve - is to step
back and let bad decisions play out, while working on independent tasks. I
consider it bad leadership, but there is also something to choosing one's
battles.

A sabbatical does indeed sound like a good way to reset. After all this time
of never taking a break by choice, its definitely something I have to figure
out: How to truly disconnect without spending everyday planning what happens
after the sabbatical is complete.

