Live data from Hacker News

Elitism as the mid-career growth engine

stkbailey.substack.com

101–110 of 115 posts

Re: Elitism as the mid-career growth engine

#101
post #29

Having spent 2 decades programming I feel I was indeed surrounded by opinionated people who were narrow minded and combative, and often I felt looked down upon regarding my tech stack or code or interests ( eg I remember there being a strongly negative bias against bitcoin in the early days). Now I know according to research most would have been on the autism spectrum and generally less socially adjusted as others wi…

> eg I remember there being a strongly negative bias against bitcoin in the early days

So, in the one example you gave, they were right. And yet I get downvoted for suggesting: hey, guys, that senior developer who's insisting on doing something a certain way? Sorry you have to hear this, but they're often right.

Re: Elitism as the mid-career growth engine

#102
post #3

> Consider the Zen of Python: if I had only one wish, it would be the end of this reference. Python has no zen, at least not anymore, and if you just want to refer to some abstract moral or best concept, please pick another quote

What makes you say that about Python?

> Explicit is better than implicit

Says the language whose code-block-endings are invisible! I will never understand the desire of people to make the important punctuation in their language invisible. Python, CoffeeScript, YAML. These people just hate being able to see the important flow-determining punctuation in their language!

Re: Elitism as the mid-career growth engine

#103

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…

I have come into serious conflict with one of my coworkers over this. He thinks everyone (except him) is either overengineering or underengineering everything all the time, but usually he just doesn't understand the problem context and is making assumptions that turn out to be incomplete or incorrect. It's a great lesson in humility to realize that no matter how smart or capable you are, you don't know what you don't…

School of Hard Knocks alumni, here.

“Good judgment comes from experience. Experience comes from bad judgment.”

Re: Elitism as the mid-career growth engine

#104

Earlier quoted context omitted.

At the same time, not everything you ship needs to be a master work. "Working well enough to ship" is not the same as "flawlessly architected". It also depends a lot on the business context, whether you can trust leadership to respect technical debt or not.

There isn't really an excuse to intentionally write crap code though. You'll normally be the one who ends up working late to fill in the gaps later.

This has been my experience.

I’ve just developed good coding habits, so even my lashups are better than many people’s final ship code.

“We are what we repeatedly do. Excellence, then, is not an act, but a habit.”

Re: Elitism as the mid-career growth engine

#105
post #101
post #29

Having spent 2 decades programming I feel I was indeed surrounded by opinionated people who were narrow minded and combative, and often I felt looked down upon regarding my tech stack or code or interests ( eg I remember there being a strongly negative bias against bitcoin in the early days). Now I know according to research most would have been on the autism spectrum and generally less socially adjusted as others wi…

> eg I remember there being a strongly negative bias against bitcoin in the early days So, in the one example you gave, they were right . And yet I get downvoted for suggesting: hey, guys, that senior developer who's insisting on doing something a certain way? Sorry you have to hear this, but they're often right .

I think there is some confusion here. I will clarify, but please don't get offended.

For your first point, no, they were wrong, I did very well on bitcoin - hence my example.

For your second point - I am confused - I agree senior developers know what they are talking about, I was one for nearly 2 decades. I was referring to peers not superiors. I was saying I have encountered narrow mindedness and ignorance. I did not say that is all I encountered. I also encountered kind, intelligent, superior and inspirational people.

Edit> On second thoughts - I re read your comment - Who downvoted you? When? Was it in regards to this article?

What on earth are you talking about?

Are you chatgpt?

Re: Elitism as the mid-career growth engine

#106

Earlier quoted context omitted.

It's not about code quality in terms of variable names and things like that, it's more about architectural decisions. What assumptions do you make, what edge cases do you cover, how much flexibility you build into the design, how extensible is it, what kind of tests do you write, etc.?

> What assumptions do you make, what edge cases do you cover, how much flexibility you build into the design, how extensible is it, what kind of tests do you write, etc.? This what I was referring to. I'm not sure there are shortcuts here beyond saving some keystrokes. As you've mentioned tests, this is one place I see a lot of people thinking they can save time not writing them out, even opting for no tests. I expec…

It's not only about the time spent physically typing, it's about the actual thinking, iterating, prototyping, etc.

Re: Elitism as the mid-career growth engine

#107
post #96

Earlier quoted context omitted.

It was good code. Some was using a database that got deprecated within our department. Some had business requirements that change pretty frequently because despite being a large company, we have some moving targets in what we deal with.

> there was this little framework someone wrote where logic was encoded in config files. This is one of the most common and traditional shining exemplars of awful code. Absolutely nightmarish stuff. Such code can only be written by someone who has absolutely no idea what programming even is . They looked at a problem and said: "You know what this problem needs? It needs a much worse programming language that I just i…

First off, I deleted the part you're replying to cause I didn't think anyone would bother reading it, but you quoted it during that time, so I apologize for the ninja edit.

The code I deleted was sensible for the business requirements at the time, and the author thought it through. It wasn't a whole DSL (which I agree is a classic mistake), was just a list of regexes and a few other variables. We had to support new pieces of inventory in our system, and adding onto the list/config was easier than rewriting code. You might fault the author for not predicting that assumptions would change and building something more flexible, but I don't think it was doable. I think the author's real mistake was spending so much time on something impossible to predict.

If I'd put more thought into structuring my new code (as I normally do for other projects), it would've been thrown away regardless, because more things they told me were "invariable" changed after I did it. And if I assumed everything was variable, it'd take way too long to write the system, so the tradeoffs pointed to writing bad code and not caring. I had several other projects on my plate that were worth spending the time on.

We had the opposite problem with another system a teammate wrote for maximal flexibility. It was composed of several carefully abstracted layers. This made the system just too complicated to deal with, as nothing even used that flexibility, and some new features even started breaking his abstractions. When he left the team, I rewrote it to only do what we need today with 1/10 the LoC, and it's way more stable. My new cross-system design has that whole thing slated for removal too. That code will live only a year.

Re: Elitism as the mid-career growth engine

#108

Earlier quoted context omitted.

> What assumptions do you make, what edge cases do you cover, how much flexibility you build into the design, how extensible is it, what kind of tests do you write, etc.? This what I was referring to. I'm not sure there are shortcuts here beyond saving some keystrokes. As you've mentioned tests, this is one place I see a lot of people thinking they can save time not writing them out, even opting for no tests. I expec…

It's not only about the time spent physically typing, it's about the actual thinking, iterating, prototyping, etc.

> it's about the actual thinking, iterating, prototyping, etc.

Yes, these are essentially constants that need to be done no matter what the code looks like. Which, again, means that the only gains you might make is in reducing the number of keystrokes. To which, I dare say a lot of those keystrokes can even be done in parallel. For example, writing tests and thinking about the problem pair quite well together, so I'm not sure you even lose an insignificant amount of time on those added keystrokes in reality.

The latter points are also where you can quickly get into time trouble if you do sacrifice your code, which is how it often takes longer if you try to shortcut the code. This would be a worthwhile gamble if poorer/less maintainable code bought you time, but in my experience it doesn't even off the hop.

Re: Elitism as the mid-career growth engine

#109
Um, a post-doc is not "mid-career." A post-doc is a beginning researcher. Just like having a black-belt does not mean you are an "expert," it means you have achieved satisfactory competence in the basics of the art and can now begin your serious study.

Re: Elitism as the mid-career growth engine

#110

Earlier quoted context omitted.

I know they don't matter when I end up being the guy to rewrite and own it, as has been my main job the past 4 (edit: 5 now) years.

That’s fair.

These might be evident in retrospect, but it's usually tricky to predict what will matter and what won't during design time. (Someone smarter than me said something about premature optimization once.)

This is also usually where experience can make a big difference.

Post reply on HN