Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elitism as the mid-career growth engine

stkbailey.substack.com

Post reply on HN
Print view View original

41–50 of 115 posts

Re: Elitism as the mid-career growth engine

#41

Post by ChrisMarshallNY »

idopmstuff wrote: post #39
ChrisMarshallNY wrote: post #23

Earlier quoted context omitted.

I worked the majority of my career at an "elite" Japanese corporation. It's one that has a brand pretty much synonymous with "Quality." Many of my peers were among the finest engineers and scientists in the world. I was often the dumbest guy in the room, and I'm smarter than the average bear. Dealing with these folks could be infuriating . Every time I would suggest orthogonal approaches (because, like, software is d…

I think the other thing that "over-engineered" can mean is code that's unnecessarily good for its purpose. If you're building a quick demo of a product to get user feedback, and you write perfect code that's highly maintainable, you've wasted time - better to throw together something as quick as you can and rebuild it if it's actually going to be used by/sold to customers. That's really overengineering in my mind - d…

> If you're building a quick demo of a product to get user feedback, and you write perfect code that's highly maintainable, you've wasted time

In my experience, this is a trap.

The demo almost always becomes the product, because upper management sees the demo, and says "Hey! It's almost done! Let's ship!"

This is how you end up with these gigantic Frankencodebases.

These days, my test harnesses and demos are generally "ship quality." It also means that I can mine them for snippets, without holding my nose.

I have spent a great deal of time, however, practicing, so that I write top-shelf code, by habit. These test harnesses are often churned out very quickly.

Re: Elitism as the mid-career growth engine

#42

Post by cratermoon »

arethuza wrote: post #22
awesomeMilou wrote: post #8

Earlier quoted context omitted.

Isn't this just cargo culting and then realizing when you're cargo culting vs when changes are actually necessary? I also don't like fawning over good code, or what makes good code, but I think it's actually a good thing to anticipate certain architectural changes. Idk, but I don't think you can tell a stakeholder that you can't implement a feature X because you didn't give enough of a shit about architecture and ran…

Over-architecting a design to be flexible in one way can be a huge problem when changes come along and they are for fundamentally different kinds of changes than were expected when the design was created - this can actually be worse than having an under-architected system.

"premature optimization is the root of all evil"

The phrase conjures up images of tight code that executes the minimum number of instructions with the least possible memory use and efficient reads and writes. In a piece of code that's executed maybe once in blue moon. Nobody bothered to profile the program and find out where the real hotspots are, so someone optimized the wrong thing.

Writing code designed to be flexible according to how the programmer believes it will need to change is also a kind of premature optimization. The code is written in the optimal way for changes along direction X to be easy. Unfortunately, when the programmer guesses wrong about the nature of future change, that work to optimize for change along X is wasted, or worse. Worse, if it makes changes along direction Y much harder.

We're pretty bad at predicting the future.

Re: Elitism as the mid-career growth engine

#43

Post by Distozion »

jacobyoder wrote: post #33
AnimalMuppet wrote: post #25

Earlier quoted context omitted.

It's almost like children versus grown-ups. Children have simplistic, almost magical thinking. Adults know the world is more complicated, and the childrens' simplistic solutions don't actually work very well. One of the reasons is small sample size. Children don't have the sample size to see why their simplistic solutions don't work. Neither does a programmer with two years of experience.

Colleague of mine working in small company. New 'CTO' hired last year. He's very much of the "everyone's voice deserves to be heard... all input is valid!" My colleague has 22 years of engineering experience across a wide range of problem spaces and industries and team sizes (large bigco to mom/pop orgs). Another guy (X) started was a year out of high school. X insists that 'tech XYZ' is the best. Current tech stack…

One of the startups I worked at had a simple rule - if you wanted to complain about something being bad, you had to come with suggestions how to make it better. And they had to be real, tangible option that could be implemented, not "how about we use technology X".

If you had nothing - you could flag something as an issue - but you were expected to either say how you suggest so solve it or shut up. You did your part of flagging the issues and that was it. It was a startup working with banks & everyone knew there are issues all around, but a lot of them we couldn't solve ourselves, because of the banks being unwilling, regulation being not clear enough if we're allowed to change anything or sometimes both.

If you came with a plan how it can be fixed while minimising the risks associated - no matter if you were junior or senior, at least you'd be listed to. If the ideas are good, the other devs would pitch in to make a realistic implementation plan. Beauty of laws & banking - if something is unclear, no one wants to touch it, so as long as you pass that hurdle - you'd get the go-ahead :D

Yes, quite a few issues ended up being ignored, but at the same time - if no one knows how to fix it, what's the point of draining everyone by continuously complaining how bad it is.

We had relatively few of meta discussion that were not product related - ever since them, I do believe that devs start focusing on code quality and "the right way to do it" only when they lack the power to make any of the product decisions.

Re: Elitism as the mid-career growth engine

#44

Post by cratermoon »

philipov wrote: post #27
shubb wrote: post #6

Earlier in my career I felt a lot of disgust at bad code and bad solutions. Sometimes it tye badness was really effort due to unfamiliarity or not instantly understanding what I was looking at.my laziness. Sometimes it was because it disagreed with what ever framework or methodology I was using to give me confidence in the face of ignorance. I feel like an imposter but at least I know design patterns so this guy who…

Playing games like Satisfactory and Factorio also forces you to come to terms with the imperfection of living systems. The first time you play, you can't possibly know how big you need the factory to be, and you don't have the tech unlocked for a lategame factory anyway. You just have to admit that you'll build a temporary facility now, and build a new one after you've unlocked the tech you'll need to scale up.

So you're saying you'll need to re-factor the facility as you gain more knowledge and resources?

Re: Elitism as the mid-career growth engine

#45

Post by dgb23 »

jacobyoder wrote: post #33
AnimalMuppet wrote: post #25

Earlier quoted context omitted.

It's almost like children versus grown-ups. Children have simplistic, almost magical thinking. Adults know the world is more complicated, and the childrens' simplistic solutions don't actually work very well. One of the reasons is small sample size. Children don't have the sample size to see why their simplistic solutions don't work. Neither does a programmer with two years of experience.

Colleague of mine working in small company. New 'CTO' hired last year. He's very much of the "everyone's voice deserves to be heard... all input is valid!" My colleague has 22 years of engineering experience across a wide range of problem spaces and industries and team sizes (large bigco to mom/pop orgs). Another guy (X) started was a year out of high school. X insists that 'tech XYZ' is the best. Current tech stack…

The saddest thing about this story is that X is missing out big time here.

I say that because I started out in a small, very cool agency. However _technical_ leadership and seniority was lacking (they admitted that and made an effort to change that.) I then stagnated on a technical level and had to accumulate that skill set own my own, often on my own time as well.

X being in the presence of a veteran like your colleague should be a golden opportunity for them to learn and grow. Of course open communication and letting everyone voice their opinions has to be part of it. But everything should be weighted, discussed and criticized based in it's objective merits for this approach to make any sense at all.

Re: Elitism as the mid-career growth engine

#46

Post by marginalia_nu »

dgb23 wrote: post #36
marginalia_nu wrote: post #24

Earlier quoted context omitted.

I think when I was younger I had in general more strong opinions on how to do things. They weren't really based on anything more than sounding like they were true. I'd hop on every paradigm that sounded correct. Clean code. Pure functions. Effective java. Pragmatic programming. Defensive programming. Like it has that righteous vibe to it. I'd totally strap a bucket on my head and go conquer the holy land under any of…

I had a very similar experience as you. But I think you're being too humble. Whether you wrote 15 applications or just one or two, does that really matter? Designing, exploring, writing, iterating on and maintaining these applications _for years_ have given you insights, battle scars and tacit knowledge that can only be gained through experience and continuous learning. Not to mention the different environments techn…

Yeah I don't deny I'm a far better programmer now than 10 years ago, and may even be better than the average in some respect, but most of it is as you say tacit knowledge.

I don't have any catchy slogans or rules to teach.

I also understand that there is so much I don't know. Even if I hone my skills until the day I die, I'll never be so certain I know the best approach as I was when I was younger.

Re: Elitism as the mid-career growth engine

#47

Post by bitwize »

mattgreenrocks wrote: post #19
butterNaN wrote: post #12

Earlier quoted context omitted.

To add to that, it's introduced as a 'simple' language. But, in 2023, the cumulative effort one puts into getting things "right" is bigger than effort you would put in learning something that's described as high learning curve. As an anecdote: Someone described elixir to be a "high learning curve" language if I wasn't exposed to Functional Programming. When I inquired how long they mean by that, the answer was 2-4 mo…

Popularity dooms the simplicity of almost every language. Re: Elixir, not surprising. Makes for more opportunities for some though.

Simplicity is for elitists.

Maybe some of you remember Didier Verna's Lisp, Jazz, Aikido: https://www.didierverna.com/blog/index.php?post/2007/04/03/L...

It's not hard to sympathize with Verna's feelings. These are all based on a similar set of philosophical guideposts: maximal output for minimal input, maximal possibilities of self-expression from a minimal set of generative rules, and understanding the deep "essence" of the craft, so that when you add your own contributions, it is by finding the "essence" of the addition and harmonizing it with the essence of existing work. And these are appealing because they give the feeling of tremendous power and the sky being the limit.

But the real world runs on the philosophy of Visual Basic, punk rock, and mixed martial arts, which are all based on a different set of philosophical guideposts: a) focus on practical solutions to real world problems; b) make getting started as easy as possible for everyone; c) it doesn't matter if added components harmonize with the original; what matters is if they contribute significant value on points a) and b), i.e., it's okay to get messy.

Re: Elitism as the mid-career growth engine

#48

Post by HybridCurve »

I do not agree with the author marketing elitism here as a desirable characteristic. There is nothing wrong with raising your standards for quality or working to be excellent within your profession but elitism generally tends embody arrogance, social stratification or other exclusionary attitudes.

You might inclined to disagree with "Well, he said 'this technical elitism' and then gave his own definitions so... ". Yes, he said that, and then proceeded to suggest it's not just acceptable, but desirable to view efforts below your standards with disgust.

There was no implication of mindfulness or humility in this process, only that it was an effective way to self motivate. There is a difference between what is sufficient and what is unacceptable. If you set your standard at excellence then anything less would be unacceptable. Tempting a mechanism as it may be for self judgement, it is a slippery slope because we often judge others to the standards we set for ourselves.

Re: Elitism as the mid-career growth engine

#50

Post by plasticchris »

ChrisMarshallNY wrote: post #41
idopmstuff wrote: post #39

Earlier quoted context omitted.

I think the other thing that "over-engineered" can mean is code that's unnecessarily good for its purpose. If you're building a quick demo of a product to get user feedback, and you write perfect code that's highly maintainable, you've wasted time - better to throw together something as quick as you can and rebuild it if it's actually going to be used by/sold to customers. That's really overengineering in my mind - d…

> If you're building a quick demo of a product to get user feedback, and you write perfect code that's highly maintainable, you've wasted time In my experience, this is a trap. The demo almost always becomes the product, because upper management sees the demo, and says "Hey! It's almost done! Let's ship!" This is how you end up with these gigantic Frankencodebases. These days, my test harnesses and demos are generall…

This is why some people will make the demos rough in some obvious ways before presenting them.
Post reply on HN