Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A bunch of programming advice I'd give to myself 15 years ago

mbuffett.com

Post reply on HN
Print view View original

91–100 of 327 posts

Re: A bunch of programming advice I'd give to myself 15 years ago

#91

Post by goosejuice »

BiteCode_dev wrote: post #78
goosejuice wrote: post #69

Earlier quoted context omitted.

Yeah let's go build some shoddy bridges and crash some planes while we're at it. Individuals can be new to a practice and feel like imposters but we shouldn't be pointing to statistics like this as an example of why it's ok. I can't believe people think like this.

Planes and bridges are problems where the quality control can be centralized and you can therefore put a lot of redundancy. Even then, the Boeing scandal shows it's not bulletproof. It's not the same for medicine. There are way more doctors than you can put safety nets. Also, when a plane crashes, it's on the news, it costs money and PR. Much less so with doctors. The plane industry is not inherently more moral, just…

Sure, we're human. There is no argument there.

However, normalizing the loss of human life as part of the learning algorithm is psychopathic. There's a time and a place to make mistakes... In mission critical situations that's in training and everywhere else we should aspire for safeguards that prevent the loss of life due to mistakes.

In medicine a lot of these deaths can be prevented through greater care. It's not different than engineering in that respect. The greater problem is decision makers putting profits over life. And this kind of mentality in this thread is just fuel for that kind of behavior. It's gross.

Re: A bunch of programming advice I'd give to myself 15 years ago

#92

Post by jameshart »

cqqxo4zV46cp wrote: post #50
jameshart wrote: post #24

Earlier quoted context omitted.

> You have imposter syndrome because you are an imposter. You are really bad. It's ok, doctors hurt people for years while learning to save them What in the medical malpractice?

Making a mistake or a reasonable but ultimately incorrect call is not malpractice. Doctors are just people, just like the rest of us, and certainly you. It’s scary if you think that the medical system is more of a safety net than it actually is, but your gripe is with the precarious nature of life, not medicine.

Figuring out how to be a doctor by faking it til you make it most definitely is malpractice though, and ‘don’t worry, you’re an imposter but you only learn by screwing up’ is very much not how doctors learn their job.

The Hippocratic oath is not ‘first, do some harm, as long as you’re learning’.

Re: A bunch of programming advice I'd give to myself 15 years ago

#93

Post by corytheboyd »

trustno2 wrote: post #13

The one thing I disagree is the thing about editors. When I began coding I spent hours tweaking my vimrc file and learning all the essentially random shortcuts, and dealing with the absurdities of vimscript. (and debugging vim plugins that broke each other.) It felt like actual work while I was producing nothing. Now I just open vscode with default settings and I am productive right away. Who cares about editors, vsc…

100% agree about defaults. I do think it’s critical you actually learn the features of you IDE. Yes being able to type fast has nothing to with programming, but being able to jump to symbols, make refactors, use keyboard shortcuts etc. reduces the gap between hands and brain.

Re: A bunch of programming advice I'd give to myself 15 years ago

#94

Post by devctx »

spoiler wrote: post #81
cm2187 wrote: post #36

Earlier quoted context omitted.

A way to rephrase your point about complexity is this wonderful quote " Developers are drawn to complexity like moths to a flame, often with the same outcome " (Neal Ford)

I've experienced this too, but I never understood why this phenomenon happens. Is it because we start adding abstractions before we understand the problems? Like, there's a certain threshold where keep things too simple makes them too complex, so people start introducing abstractions to reduce complexity. But often it's the wrong abstractions and then we accidentally end up with worse complexity that's harder to unra…

The commonly used term, also mentioned by Fred Brooks, is accidental complexity. Accidental highlights the non intentional nature of devs introducing complexity.

Re: A bunch of programming advice I'd give to myself 15 years ago

#95

Post by efitz »

I loved the author's point on "incidental complexity". I would point out though, that even if you CAN explain why something is complex doesn't mean it SHOULD be complex.

When the subject of "tech debt" comes up, I always tell the teams I work on to focus on tasks that improve our speed or agility in the future. I believe that many coding tasks actually have a negative dev cost over time, as they reduce the dev costs of future work more than they cost at the current moment to implement. (Of course the problem is that they have a positive dev cost in the current sprint, so good luck convincing decision makers...)

Re: A bunch of programming advice I'd give to myself 15 years ago

#96

Post by necrotic_comp »

valyala wrote: post #88

My advices to new software engineers: - Always think how to simplify the code you write, since simple code is easier to maintain and debug. - Prefer writing dumb code than smart code. Smart code is good for programming contests. Smart code is very bad in production when it needs to be debugged or refactored. - Always think about improving the usability of the software product you work on. Users don't care about code.…

I go a step further on "dumb code". Write code that is easy to reason about, understand, and grok the implications of.

I spent a ton of time doing support and engineering on a trading desk, where our SLA for an outage was somewhere in the range of 30 seconds to 5 minutes. Having super simple code that makes it easy to understand what the code problem is (if not necessarily the business problem) lets you move on with life and let the business keep moving.

Re: A bunch of programming advice I'd give to myself 15 years ago

#97

Post by farmeroy »

photochemsyn wrote: post #70

> "It’s really easy to write terrible code. But it’s also really easy to write code that follows absolutely every best practice, with 100% test coverage, and has been fuzz-tested and mutation-tested for good measure – your startup will just run out of money before you finish. So a lot of programming is figuring out the balance." The situation appears to be changing rapidly. 15 years ago there were no advanced code-ge…

What sort of tests does it seem good at generating? I was hoping it would give me a decent start writing tests with Jest and React Testing Library for an already existing but untested codebase. It seemed ok at small components that I can also quickly write tests for, but the larger, messier things would receive useless, failing tests.

Re: A bunch of programming advice I'd give to myself 15 years ago

#98

Post by Scubabear68 »

The author’s comments about knowing your business context and the potential impact of bugs really hit home with me.

I have seen far too many teams using Facebook sized solutions for a few thousand users.

I’ve seen developers slowed to an absolute crawl, terrified of shipping code, for a completely secondary operational platform with low volumes and non-critical data. All because the product people were misguided in their mission.

And sadly, I’ve seen teams with almost non-existent security practices and knowledge happily banging out crap in financial services environments.

And I’ve been blessed with teams understanding their position and fully embracing it. Financial services products with quarterly releases that were rock solid and well architected. Batch document processing systems with just a few dozen end users who worked closely with us developers to tune algorithms where sometimes we would ship multiple times in a day and re run batches in production.

To be successful, teams gotta know if you’re at NASA level, or life threatening, or business critical, or somewhat critical, or just nice tooling, plus understand the cash flow / budget situation. As a dev you may not be privy to all that, but strive to know as much of this as you can.

And of course, understand who you users are, and who your customers are, and prioritize accordingly.

Re: A bunch of programming advice I'd give to myself 15 years ago

#99

Post by liampulles »

"Bad code gives you feedback, perfect code doesn’t. Err on the side of writing bad code".

This is probably quite a cynical way of putting it (and it speaks to me, probably because I am quite cynical) though I don't know if a junior dev will really appreciate this.

The way I would put it is: don't seek satisfaction from trying to make perfect abstractions for business rules no one quite understands, rather seek satisfaction from making your user's lives easier as efficiently as possible.

Re: A bunch of programming advice I'd give to myself 15 years ago

#100

Post by lukan »

valyala wrote: post #88

My advices to new software engineers: - Always think how to simplify the code you write, since simple code is easier to maintain and debug. - Prefer writing dumb code than smart code. Smart code is good for programming contests. Smart code is very bad in production when it needs to be debugged or refactored. - Always think about improving the usability of the software product you work on. Users don't care about code.…

Or in short, KISS!

(Keep it simple stupid!)

And yes, users will notice the button that is only half visible quite a bit more, than a suboptimal sort algorithm.

Post reply on HN