Live data from Hacker News

After 14 years in the industry, I still find programming difficult

piglei.com

81–90 of 207 posts

Re: After 14 years in the industry, I still find programming difficult

#81

Earlier quoted context omitted.

Most of those processes, tps reports, jira and other annoyances is because in a programming environment you literally have too many cooks in the kitchen. Every programmer can create the system from scratch, so to prevent them from doing so, we have to make it super annoying. Basically it's a people problem. The most incredible work happens in the first 3 months by a lone developer green-fielding with no boundaries. T…

Hum... When the computer we command run into that kind of problem, it's almost universally better to fix incompatibilities post-fact with an exceptional process than it's to avoid creating them. But somehow, people are never allowed to do that. But rest assured that if you need a heavy process just to coordinate a handful of developers, you have a bad architecture. Even if you do pessimistic preemptive coordination.

Yeah, his "very large system" is just that way because it is modelled after the organization/team structure. Unavoidable.

Re: After 14 years in the industry, I still find programming difficult

#82

IMO it massively depends on what you're working on. I work on some codebases that are primarily about moving data around in Go. There are patterns to follow, there are no tricky algorithms, concurrency is largely solved, etc. All the challenge is about the broader engineering task of developing requirements, communicating, managing risks of deployment, stuff like that. Then, I work on kernel code where it takes me mo…

It might be the case that, the "hotter" the code paths that you're writing are (the more they get executed), the more difficult it is to write that code, where as for "colder" paths (of which there are so many more), the code isn't as difficult but there is a lot more overhead of managing complexity, business priorities, process, communication, etc.

Linux kernel code is probably some of the hottest code on the planet, and the developers/community understand that contributors need to be able to do exactly what you are doing - spending months toiling over a few hundred lines, and making sure that they are as perfect as can be, because literally billions or even _trillions_ of systems will depend on that code path. It is understood that in order to get it correct, performant, and maintainable, there is no other option other than to have a skilled developer take on a very high cognitive load in order to correctly implement the task.

For colder code paths, like business logic (e.g. customer registers, happens "once" per customer), that logic evolves with the team, the team evolves with the company, the company evolves with the business, the business evolves with the market, which evolves with the world. The code might be pretty simple and easy to write, but the conversations around priorities and complexity and "why are we doing this" take up the lions share of the mental effort around it. Also exhausting...

TLDR it is much harder to write systems code than it is to write python code that makes a call to an API and saves a record in a database, and working on the former _perhaps_ gives you more opportunity to be shielded from typical "software engineering" toil of business communication.

Re: After 14 years in the industry, I still find programming difficult

#83

Been programming over 30 years, since I was 8 years old and my dad’s coworker gave me his old BASIC programming books and I was hooked. I have always found programming easy, and still do. It is just fun, and I still love learning new languages and tools and paradigms. It is still my favorite hobby. However, WORK is hard. Dealing with office politics and changing priorities and bad leadership and meetings and TPS repo…

Did I write this? Are you me???

Re: After 14 years in the industry, I still find programming difficult

#84

Reading the comments here, I am having a total Slashdot throwback moment. Did anybody actually read TFA? Most of the replies I am seeing here seem to have treated the article's title as a writing prompt. Read the whole article friends - it's got a nice amount of nuance and the author unpacks what they mean by "difficult" very well.

I remember reading analysis showing that there is a high correlation between the order that comments are posted and how many votes they get, i.e. early comments tend to get most voted. I guess people are gaming the system by commenting quickly. Who has time to read a 10 min article and comment when you can not read it and post a platitude?

Re: After 14 years in the industry, I still find programming difficult

#85
I really enjoyed this and it has lots of great lessons.

One small point though. I noticed this paragraph:

“From a certain perspective, software is inherently designed to be modified (why else would it be called "software"?). This makes developing software fundamentally different from building houses. After all, nobody would say after constructing a building, "Let's knock it down and rebuild it! The same structure but with 30% less steel and concrete!"”

It’s odd to me the author doesn’t see the connection from the instance of the software and the code. In this example, the instance is the house and the code is the blueprint. Code and blueprints change ALL the time. So I think it is false to suggest software engineering is somehow different from other engineering disciplines. I’d say it’s exactly the same but with a whole lot less ethical considerations, largely due to reasoning like above.

Great read, I just had to point that out though.

Re: After 14 years in the industry, I still find programming difficult

#86
> As "wordsmiths," programmers often neglect reading. However, reading is an essential part of quickly improving your programming skills.

I'm always surprised to hear that most programmers dislike code reviews. I've found code reviews to be one of the most useful ways to learn new design patterns and language features. I personally believe that adopting a mindset of curiosity helps make code reviews enjoyable rather than tedious.

Re: After 14 years in the industry, I still find programming difficult

#87

Been programming over 30 years, since I was 8 years old and my dad’s coworker gave me his old BASIC programming books and I was hooked. I have always found programming easy, and still do. It is just fun, and I still love learning new languages and tools and paradigms. It is still my favorite hobby. However, WORK is hard. Dealing with office politics and changing priorities and bad leadership and meetings and TPS repo…

This is why I don't worry too much about AI. It can write the code better and faster than I do? Wow, you just freed up 5% of my day.

Now you can spend 10% of your day reviewing AI written code!

Re: After 14 years in the industry, I still find programming difficult

#88

Reading the comments here, I am having a total Slashdot throwback moment. Did anybody actually read TFA? Most of the replies I am seeing here seem to have treated the article's title as a writing prompt. Read the whole article friends - it's got a nice amount of nuance and the author unpacks what they mean by "difficult" very well.

I feel quite a lot of people on HN simply react to the titles and that's it. Many people on HN also only read the comments. I know I do. I also sometimes read the post, it really depends.

I do the same. I'm not really here for the articles - they're secondary - but for the excellent discussions by the community

Re: After 14 years in the industry, I still find programming difficult

#90
I'm happy to say that my company writes "good" code, at least on the production side, and I have genuinely learned a ton and become a better engineer while working here. The experimental, test, and sometimes CI code is shit. Test code makes sense, it's immature prototype. CI should be much better than it is, it's extremely fail-safe and its false-positive rate is a major headache for the entire software org. But our production code is genuinely very good. You won't get a PR merged with literals in code or custom functions that could be replaced by STD functions or unnecessary copy operations, or without thorough design documentation and comprehensive unit tests and CPU load test results and a review of the effects of your change on near and distant stakeholders. (Our code could literally kill large numbers of people, so it's a good idea to maintain these standards.)

Previously I worked for half a dozen early-stage startups that wrote super-janky demo code that would have to be power-cycled multiple times to get to a fully operational state and no one at the company had more than a year experience outside academia so founders didn't see a problem with that level of reliability. In those roles I learned a lot about math and dealing with giant egos, but not much about software engineering.

Point is, there are companies who rigorously enforce good code requirements, where you can learn from others and improve your skills, where "good code" is the norm.

Post reply on HN