Live data from Hacker News

Elitism as the mid-career growth engine

stkbailey.substack.com

111–115 of 115 posts

Re: Elitism as the mid-career growth engine

#111

Earlier quoted context omitted.

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.

When in doubt, best to start with something quick n' dirty and not worry too much about what happens when it becomes inadequate. Just make sure it can be easily replaced when needed, which means treating everything you write as disposable. When using hindsight, you can build something better.

There's a big back-and-forth thread about this where I explain why well-written code on our team ends up being deleted within 1-2 years, and the author's only mistake was spending so much time deliberating over the code.

Re: Elitism as the mid-career growth engine

#112

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.

So funny - I was tracking till the end. I thought you meamt the die hard proponents of these software dev tropes are the childlike ones. Imo I think that is more apt. I see a lot of resources wasted in the name of conforming to standards when the standard does t really apply to the partocular scenario

Either you misunderstood my post, or you are explaining what you think badly, because I think I am in agreement with what you wrote in your last paragraph.

Re: Elitism as the mid-career growth engine

#114

Earlier quoted context omitted.

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.

When in doubt, best to start with something quick n' dirty and not worry too much about what happens when it becomes inadequate. Just make sure it can be easily replaced when needed, which means treating everything you write as disposable. When using hindsight, you can build something better. There's a big back-and-forth thread about this where I explain why well-written code on our team ends up being deleted within…

“Just make sure it can be easily replaced when needed”, implies a clean architecture of some kind - which implies experience.

Perhaps you’re just better than you realize.

Re: Elitism as the mid-career growth engine

#115

Earlier quoted context omitted.

When in doubt, best to start with something quick n' dirty and not worry too much about what happens when it becomes inadequate. Just make sure it can be easily replaced when needed, which means treating everything you write as disposable. When using hindsight, you can build something better. There's a big back-and-forth thread about this where I explain why well-written code on our team ends up being deleted within…

“Just make sure it can be easily replaced when needed”, implies a clean architecture of some kind - which implies experience. Perhaps you’re just better than you realize.

Eh, if you're given a well-separated API to deal with, the code can be pretty terrible without being hard to replace. What makes it hard to replace is when someone puts a lot of thought into it and doesn't want you to rewrite it.
Post reply on HN