←back to thread

The best programmers I know

(endler.dev)
628 points kiyanwang | 7 comments | 09 Apr 25 06:02 UTC | HN request time: 0s | source | bottom
Show context
bob1029 ◴[09 Apr 25 10:31 UTC] No.43630646[source]▶
Not guessing is perhaps the most important thing to the business.

I developed a lot of my problem solving skills in semiconductor manufacturing where the cost of a bad assumption tends to be astronomical. You need to be able to determine exactly what the root cause is 100% of the time or everything goes to hell really fast. If there isn't a way to figure out the root cause, you now have 2 tickets to resolve.

I'll throw an entire contraption away the moment I determine it has accumulated some opacity that antagonizes root cause analysis. This is why I aggressively avoid use of non-vanilla technology stacks. You can certainly chase the rabbit over the fence into the 3rd party's GitHub repo, but I find the experience gets quite psychedelic as you transition between wildly varying project styles, motivations and scopes.

Being deeply correct nearly all of the time is probably the fastest way to build a reputation. The curve can be exponential over time with the range being the value of the problem you are entrusted with.

replies(5): >>43631055 #>>43631842 #>>43632734 #>>43637040 #>>43638701 #
Taek ◴[09 Apr 25 11:44 UTC] No.43631055[source]▶
I always get a lot of pushback for avoiding frameworks and libraries, and rolling most things by hand.

But, most frameworks and libraries aren't built to be audit-grade robust, don't have enterprise level compatibility promises, can't guarantee that there won't be suprise performance impacts for arbitrary use cases, etc.

Sometimes, a third party library (like sql-lite) makes the cut. But frameworks and libraries that reach the bar of "this will give me fewer complications than avoiding the dependency" are few and far between.

replies(8): >>43631189 #>>43631275 #>>43631326 #>>43632119 #>>43632384 #>>43635012 #>>43635674 #>>43644940 #
pc86 ◴[09 Apr 25 13:52 UTC] No.43632119[source]▶
This is smart if you work for a company that actually needs this level of robustness. The problem is that most don't, and a lot of people who work for these companies wish they were working someone "better"/"more important," so they pretend they actually do need this level of performance.

The guy like you on a mission critical team at a cutting edge company is a godsend and will be a big part of why the project/company succeeds. The guy who wants to build his own ORM for his no-name company's CRUD app is wasting everyone's time.

replies(4): >>43632378 #>>43632716 #>>43632815 #>>43658889 #
1. ryandrake ◴[09 Apr 25 14:44 UTC] No.43632716[source]▶
I think many engineers would highly benefit from doing a 1-2 year stint working on safety-critical embedded software, where there are correctness requirements, and lives are lost if you're wrong or careless. It may not be everyone's bowl of soup, but it would at least expose you to that side of the world and you might learn something from the experience. Perhaps if everyone did this kind of tour of duty, something would rub off, and there would not be so much casual yolo carelessness in the "normal" software world.
replies(3): >>43632826 #>>43633862 #>>43634548 #
2. tacitusarc ◴[09 Apr 25 14:52 UTC] No.43632826[source]▶
On the other hand, do I want careless devs working in those industries?
replies(2): >>43633287 #>>43635135 #
3. ryandrake ◴[09 Apr 25 15:33 UTC] No.43633287[source]▶
I don't think "careless" is a permanent, intrinsic attribute of a developer. It's something they learn to be, and it can be unlearned.

We respond to incentives. If a developer's only incentive is "we reward shipping as fast as possible" then they will carelessly ship slop as fast as they can type it. If that incentive is removed, they can learn a better way...

4. jandrewrogers ◴[09 Apr 25 16:22 UTC] No.43633862[source]▶
Anecdotally, working on mission-critical always-on systems when I was a junior developer was influential on the development of good habits when writing code that have carried through in contexts where such code quality was not required. In my view I benefited greatly from this exposure early in my career.

A lot of it is pretty basic: checking every single return code, testing every single branch, verifying that the external environment is doing what it claims or should be doing. All of this is muscle memory now, I find it difficult to write a throwaway python script without doing this. I also don’t feel like the degree of thoroughness I put into it significantly slows down development either compared to other developers that YOLO it a bit more; I spend a bit more time writing it, they spend a bit more time debugging it in test. And in prod, the former approach has lower defect rates.

It doesn’t need to be safety critical embedded software, which has a somewhat niche set of problems. Even fairly high-level data infrastructure has many of these same challenges.

replies(1): >>43638368 #
5. hiAndrewQuinn ◴[09 Apr 25 17:07 UTC] No.43634548[source]▶
I'm not averse to working on safety critical stuff in a vacuum but if they expect me to do safety critical stuff at the same pace I do my very non-safety critical stuff I'm going to expect a significant salary premium, probably at least 1.5x up from what I'm making currently. I need to charge more if I'm going to be directly responsible for the loss of lives, because sooner or later I'm going to start losing sleep over it.
6. rcxdude ◴[09 Apr 25 17:55 UTC] No.43635135[source]▶
From my experience in the industry, if the average backend dev went to work in that industry, the average level of competence would go up (compare the average salary, for one thing). The processes are all about making it hard to fuck up really badly, they're very much not going to weed out 'careless' devs, just limit the damage they can do.
7. j45 ◴[09 Apr 25 21:46 UTC] No.43638368[source]▶
It seems like languages like Go promote this kind of development innately. I'm relatively new to it but found that much interesting about it.