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

81–90 of 115 posts

Re: Elitism as the mid-career growth engine

#81

Post by hot_gril »

noobker wrote: post #37
sanderjd wrote: post #32

Earlier quoted context omitted.

I don't have many complaints about the language itself, but I've found the packaging ecosystem to be the most complicated and frankly dysfunctional that I've used in the last decade.

I never understand this complaint when Javascript/Typescript is sitting there with a mess of .lock and .json files across multiple tools that sometimes interoperate and sometimes don't. Package management isn't a solved problem; Python employs standard patterns for it; Significantly better than chained Makefiles from my C-development days.

NodeJS has NPM, which is simple. Usually when you want to run someone else's NodeJS project, you `npm install && npm start`. Most Python projects have a Dockerfile, which shows you how bad the actual package management is.

TS is just JS but with extra things that can go wrong (Babel etc) and not being able to use simple `require` syntax anymore and some not-very-automatic type checking that you don't need; I don't use it. It's like taking a steak fresh off the grill and smothering it with mayonnaise.

Re: Elitism as the mid-career growth engine

#82

Post by hot_gril »

fud101 wrote: post #5
rtodea wrote: post #3

Earlier quoted context omitted.

What makes you say that about Python?

it's become a complicated language with many different ways to do the same thing but none of them very good

I came back to Python after several years, and there's type-checking now, which we're required to use at work. Way to ruin the entire point of Python.

Also, Python's async stuff was always terrible until they introduced the new async/await feature, but I suppose that's part of the "many ways to do the same thing" you mention. They should've done it from the beginning IMO, but it was hard to predict maybe.

Re: Elitism as the mid-career growth engine

#83

Post by stinkbutt »

marginalia_nu wrote: post #46
dgb23 wrote: post #36

Earlier quoted context omitted.

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.

[dead]

Re: Elitism as the mid-career growth engine

#84

Post by feoren »

hot_gril wrote: post #78
feoren wrote: post #63

Earlier quoted context omitted.

> It's code. No one is going to read it. It will be replaced next year. Then it truly is awful. Deeply awful. It sounds like you've never progressed past dealing with terrible code, so you have my condolences. Good code is read. Good code is not replaced in a year. Even most bad code is not replaced in a year. Truly you live in a world of absolute shit code.

Business requirements or engineering dependencies can change quickly in some scenarios, meaning code gets replaced regardless of its quality. I've had to delete a lot of code the past few years, much of it 1 year old and very carefully written. Someone wasted his time.

Obviously I don't know the specifics of your situation, but "very carefully written" doesn't necessarily equate to "good". Part of what makes good code good is its flexibility in the face of change. Barring an early-startup-style total pivot to a completely different industry, business requirements shouldn't just completely change like that, unless they were incompletely fleshed out. I could see some kind of API-adapter code having to be completely thrown out if you move away from that API or dependency; indeed you're right that that doesn't need to be great code since there's no expectation of deeper reusability there.

I do think a lot of code is written prematurely, which may be what happened there. If code is premature, it's not worth spending the time to make it good; but most likely, it's not worth writing at all. A large majority of the total time on a task is spent fully understanding the problem being solved, with much of the remainder spent coming up with a high-level approach to the solution. Actual meaty code-writing is a pretty low percentage, so even doubling the time spent here shouldn't increase your overall time that much. Since writing the code is the crystallization of all that prior effort, you can liken writing good code to "taking good notes". It indeed seems silly to say "man, someone wasted a lot of time taking really good notes about that lesson they were in." If it was not worth spending time to take great notes on the lesson , then the lesson itself was not worth it.

Re: Elitism as the mid-career growth engine

#85

Post by tracer4201 »

> But elitism only becomes useful at a particular stage of development. Earning the white belt is almost purely knowledge and a bit of practice. Getting to the black belt requires not just skills, but a mindset: determination, resolution, and yes, snobbiness. You must believe that having a black belt is worth the effort and that having a black belt is better than not having one.

I think it’s even simpler than this white/black belt metaphor.

Driving your career forward requires delegation, scaling yourself through others. Doing this effectively requires having strong opinions. The author is referring to these opinions as elitism, which is jarring to me. It could be elitism or simple pragmatism.

Quite a few posts here are referring to code quality. People often forget that programmers aren’t paid to write the prettiest code or have the most beautiful abstractions. VALUE is what we want to produce.

I once found myself insulting a monolithic code base only to later realize that mess of a code base has shipped in over 10 million devices and a product rated over 4.5 stars on Bestbuy, Amazon, and many more retailers. It’s entire ecosystem had directly and indirectly generated billions of dollars in sales.

Meanwhile, my own teams’ clean code with well thought abstractions hadn’t generated any revenue at all. In fact, this other “piece of shit” that came before paid for all our compensation.

Re: Elitism as the mid-career growth engine

#86

Post by hot_gril »

feoren wrote: post #84
hot_gril wrote: post #78

Earlier quoted context omitted.

Business requirements or engineering dependencies can change quickly in some scenarios, meaning code gets replaced regardless of its quality. I've had to delete a lot of code the past few years, much of it 1 year old and very carefully written. Someone wasted his time.

Obviously I don't know the specifics of your situation, but "very carefully written" doesn't necessarily equate to "good". Part of what makes good code good is its flexibility in the face of change. Barring an early-startup-style total pivot to a completely different industry, business requirements shouldn't just completely change like that, unless they were incompletely fleshed out. I could see some kind of API-adap…

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.

Re: Elitism as the mid-career growth engine

#87

Post by stinkbutt »

hot_gril wrote: post #78
feoren wrote: post #63

Earlier quoted context omitted.

> It's code. No one is going to read it. It will be replaced next year. Then it truly is awful. Deeply awful. It sounds like you've never progressed past dealing with terrible code, so you have my condolences. Good code is read. Good code is not replaced in a year. Even most bad code is not replaced in a year. Truly you live in a world of absolute shit code.

Business requirements or engineering dependencies can change quickly in some scenarios, meaning code gets replaced regardless of its quality. I've had to delete a lot of code the past few years, much of it 1 year old and very carefully written. Someone wasted his time.

[dead]

Re: Elitism as the mid-career growth engine

#88

Post by randomdata »

nerdponx wrote: post #79
randomdata wrote: post #68

Earlier quoted context omitted.

> 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 Any time I thought I could shortcut my way to a demo by relaxing on perfect code/maintainable code it has always ended up taking just as much time and often longer.

Almost every time I've thought to myself "I will probably need to refactor this later", I did indeed need to refactor it later. But I think a lot of those cases I still made the right decision. The initial version took M hours to develop, and the refactor took N hours. If I had done it right the first time, it would have taken L hours, where M < L < N + M. But it's not hard to construct legitimate business scenarios…

I expect M ≈ L, though. All you can ever gain by relaxing code quality is some keystrokes, but I'm not sure typing is a bottleneck to begin with. The bulk of the work required is the same no matter what the code looks like. I've often believed that M < L when I've tried to take shortcuts, but in hindsight I'm not sure it has ever ended up being meaningfully true.

Re: Elitism as the mid-career growth engine

#90

Post by joncp »

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…

> No one is going to read it. It will be replaced next year

I've never seen this happen even once in my 25 years as a developer.

Quite the opposite, in fact. Codebases grow and become more entrenched every year the organization stays in business. The goal becomes to shoehorn into the product more and more features that the original designers never dreamed of. And those original devs are usually long gone. To do that shoehorning long-term in the face of developer churn requires intense discipline around communicating to the next person what you are doing and why.

Post reply on HN