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.
Things I’ve learned in my 20 years as a software engineer
281–290 of 745 posts
Re: Things I’ve learned in my 20 years as a software engineer
#282Earlier 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.
Re: Things I’ve learned in my 20 years as a software engineer
#283This 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…
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
#284Earlier 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.
Re: Things I’ve learned in my 20 years as a software engineer
#285The 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…
Re: Things I’ve learned in my 20 years as a software engineer
#286Earlier 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.
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.
Re: Things I’ve learned in my 20 years as a software engineer
#287Earlier 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 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…
- 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
#289The 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…
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
#290The 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.