Live data from Hacker News

Things I’ve learned in my 20 years as a software engineer

simplethread.com

281–290 of 745 posts

Re: Things I’ve learned in my 20 years as a software engineer

#281
post #269

40+ years of experience here, and I'll tell you the #1 thing I've learned: * Software is a social service. Its for other humans. Incredibly, it doesn't matter how educated the developer, they still seem to have to learn this lesson themselves, over and over, until it sinks in...

A corollary-ish observation of my own: * If coders could write useful documentation (starting w/inline comments) they probably wouldn't be coders.

They would be what then?

Re: Things I’ve learned in my 20 years as a software engineer

#282
post #244
post #152

Earlier quoted context omitted.

> Dealing with python environments and packages makes me want to avoid python if at all possible. I see this a lot, and I don't blame folks for having this stance. It's taken me over a decade to dial in my workflow. Quick rundown: - don't use python2. Ever. - don't use the system python, or brew python for anything other than bootstrapping - only use `pip install --user` for exactly one thing: `pip install --user pip…

I think the fact that you feel working with python requires adhering to a specific 12-step programme may go some way to explaining why I've never gotten comfortable with it.

I love Python and the Python 2-3 debacle really soured things for me as well. It was hard to get over that hump and I can understand that many were put off by it forever.

Re: Things I’ve learned in my 20 years as a software engineer

#283
post #260
post #6

This is a very insightful list. But there is one thing I'd quibble with: while it's inherently a super-subjective metric, I would say that 10x programmers do exist. Both in the "can support a company by themselves" sense and the "mad lone genius" sense. Not all the 10x programmers are good at working with other people or on other people's ideas. 0.1x programmers are often lost or afraid, although they may just be uni…

> while it's inherently a super-subjective metric, I would say that 10x programmers do exist Even worse than super-subjective, it seems like people don't agree on the definition of "10x programmer". Is that 10x value (code * code quality) produced per unit of work-time? Per brain cycle? Are you controlling for programmer experience, or domain knowledge, as [1] pointed out? Do you actually mean 10x, or is that a stand…

Have a 1 year project. One side is a team of 10 developers with 5 years of experience in the field. Other side is 1 developer with 5 years of experience in the field. Do you think it is unreasonable that there is any developer that could beat the team in that situation? The quality expectations for both are the same, so no shortcuts.

I don't find that unreasonable at all, most teams are very unproductive. So what I'd call it is "A 10x developer is a developer who can outperform a typical team of 10 developers".

Re: Things I’ve learned in my 20 years as a software engineer

#284
post #11

Earlier quoted context omitted.

you can replace the word "software" with basically any other professional work and that is still the same. I don't know what you can learn from the fact that it's a social service.

I've met a lot of people who are writing code to satisfy requirements and collect a paycheck. They're good people, but just don't automatically think about the end user. They stop when the requirements are met, instead of when the user will be happy. That's what they're supposed to learn from that, IMO.

Some organizations are structured such that it is difficult for an engineer to do anything else. An engineer doesn't always have access to the end user, unfortunately.

Re: Things I’ve learned in my 20 years as a software engineer

#285

The 10x programmer is a silly myth. The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly. You know, 10x is an optimistic number here. Some programmers will do in 1 day what you wont achieve in a life time. And not understanding that makes you a bad programmer by my book simply because this is the foundation of the job. So let…

When you say "[s]ome programmers will do in 1 day what you wont achieve in a life time" you are no longer talking about the 10X programmer myth. You're talking about invention, rather than day-to-day productivity.

Re: Things I’ve learned in my 20 years as a software engineer

#286

Earlier quoted context omitted.

Make an API out of that. There is huge demand for it.

I believe such an API already exists: https://pdftables.com/ (no affiliation). Went to a presentation at a Golang meetup in Amsterdam by the guys behind this company. Seemed to know their stuff. But I have no real world experience using it.

I had a look - from their FAQ [0]:

However, some PDFs are scanned documents, or only contain images. PDFTables doesn't perform Optical Character Recognition (OCR) to turn these images into text.

To process these kinds of documents, you will need to either enable OCR in your scanning software, or run the PDF through specialist OCR software before using PDFTables.

[0] https://pdftables.com/faq

Re: Things I’ve learned in my 20 years as a software engineer

#287
post #187
post #142

Earlier quoted context omitted.

> They stop when the requirements are met, instead of when the user will be happy. that's because they are doing software "for other humans" - aka, their manager and PM, who gave them the requirements. So the problem is not the software engineer, but the person who creates those requirements to be fulfilled.

I think what the parent may have been complaining about is essentially myopia in interpreting things - ‘well, this technically checks the box of what they ask for’ while willingly avoiding thinking about the larger context of what is being attempted or trying to understand requirements that don’t make much sense. Don’t get me wrong - it has it’s place, and if everyone always tried to understand everything, there are…

> I think what the parent may have been complaining about is essentially myopia in interpreting things - ‘well, this technically checks the box of what they ask for’ while willingly avoiding thinking about the larger context of what is being attempted or trying to understand requirements that don’t make much sense.

I think what your post’s parent was pointing out is that in lots of environments, such myopia is just an engineers job definition, for which they will be punished if they stray. Interpreting end-user needs is someone else's job.

Re: Things I’ve learned in my 20 years as a software engineer

#288

> I’d rather someone give me opinions that I violently disagree with than for them to have no opinions at all. I've been a developer for 15 years... anybody else feel like the further they get into their career, the more they want to keep their opinions to themselves? I feel like as a junior dev I had way stronger opinions and I was a lot more vocal about them. Now, I still have opinions, but I've learned that nobody…

No, I've been doing this for ~30 years now and I have really strong unpopular opinions on things. Like:

- NPM/Yarn/Gems etc is a disaster waiting to happen. Having lots of dependencies is a security nightmare and a maintenance issue. As these projects get dropped by their original maintainers we'll start seeing more supply-side attacks and more vulnerabilities going unpatched.

- Docker is a great solution for a specific problem. But I don't think it needs to be used for everything. Same for K8s. Same for microservices architecture.

- Simplicity is an important design goal for all systems. Complexity breeds bugs. Boilerplate is simple. DRY can be taken too far. Every abstraction layer leaks at least a little. "clever" code is usually not what is needed for reliable software.

I expect to get downvoted because these are unpopular opinions. But I'm used to arguing about them. It's always interesting to discuss.

Re: Things I’ve learned in my 20 years as a software engineer

#289

The 10x programmer is a silly myth. The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly. You know, 10x is an optimistic number here. Some programmers will do in 1 day what you wont achieve in a life time. And not understanding that makes you a bad programmer by my book simply because this is the foundation of the job. So let…

This is always my go to example of a 10x programmer:

https://norvig.com/spell-correct.html

How many developers do you know that would bang out a spelling corrector on a single plane flight, in half a page of code?

It's a question of knowing the algorithms of tools that make things possible that other developers might not even consider, and how to express those ideas cleanly and concisely, evaluate your solution, and iterate and improve quickly.

And then consider the quality of his documentation and considerations for improvement and future work.

Re: Things I’ve learned in my 20 years as a software engineer

#290

The 10x programmer is a silly myth. The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly. You know, 10x is an optimistic number here. Some programmers will do in 1 day what you wont achieve in a life time. And not understanding that makes you a bad programmer by my book simply because this is the foundation of the job. So let…

I'm about 1/1,000,000th a Fabrice Bellard, and I'm fine with that.

Bellard is who I reference in these situations also. He's a sort-of empirical refutation of the assertion "10x programmers don't exist". I always liked that he lists qemu and ffmpeg on his website as afterthoughts mixed in with all the other code he's written.
Post reply on HN