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

My guiding principles after 20 years of programming (2020)

alexewerlof.medium.com

Post reply on HN
Print view View original

161–170 of 193 posts

Re: My guiding principles after 20 years of programming (2020)

#161

Post by codebje »

tdrgabi wrote: post #88
bambam3000 wrote: post #44

Earlier quoted context omitted.

this is such a poor analogy

I give you that, haven't spent much time on coming up with it. I would like a competent plumber and if he does some fancy work in his spare time and gets even better than great. But I would raise an eyebrow if beside my work he will also want to be paid for 6 hours he spent in the weekend, experimenting on his bathroom...

I wouldn't expect to have professional development overtly included in a short term contract, either. I'd expect a much higher hourly rate to pay for it though, amongst other things.

I'd expect if the plumber worked for a plumbing company they'd probably invest some time and money into skills growth, and pay for it out of the money they charge you.

Re: My guiding principles after 20 years of programming (2020)

#162

Post by mandevil »

JKCalhoun wrote: post #94
usrbinbash wrote: post #21

> Never start coding (making a solution) unless you fully understand the problem. While I agree with this in general, I find that to reall fully understand a problem, I need to attempt to code, or at least formulate, a solution to it. a) because when I break down a problem into its code-able component parts, I learn a lot about it b) because in the process of then actually implementing these parts I often discover ed…

Yeah, it could just be me, but I prefer to make two false starts, toss them, and then get it right on the third attempt rather than attempting to whiteboard the problem for two weeks. Not only is it more interesting to me to try three different ways to tackle a problem, but I have been burned when the two weeks of whiteboarding missed something and I'm back to having to iterate anyway. To be sure, I do a little white…

Fred Brooks' other famous bit (besides the "mythical man month"): "You should plan to throw one away. You will anyway."

Re: My guiding principles after 20 years of programming (2020)

#163

Post by irrational »

> Always have pet projects.

I strongly don’t agree with this one. In my opinion, a well rounded individual will have hobbies and a life outside of programming that won’t leave time for pet projects.

Having said that, I do have a pet project that I’ve been “working on” for about 15 years. Maybe I’ll find some time to make some progress on it after I retire.

Re: My guiding principles after 20 years of programming (2020)

#164

Post by barrucadu »

irrational wrote: post #163

> Always have pet projects. I strongly don’t agree with this one. In my opinion, a well rounded individual will have hobbies and a life outside of programming that won’t leave time for pet projects. Having said that, I do have a pet project that I’ve been “working on” for about 15 years. Maybe I’ll find some time to make some progress on it after I retire.

Why can't someone be a well-rounded individual with hobbies and a life outside of programming, and also have time for pet projects?

Re: My guiding principles after 20 years of programming (2020)

#165

Post by MrPatan »

usrbinbash wrote: post #21

> Never start coding (making a solution) unless you fully understand the problem. While I agree with this in general, I find that to reall fully understand a problem, I need to attempt to code, or at least formulate, a solution to it. a) because when I break down a problem into its code-able component parts, I learn a lot about it b) because in the process of then actually implementing these parts I often discover ed…

Analysis through synthesis

Re: My guiding principles after 20 years of programming (2020)

#166

Post by WalterBright »

> Never start coding (making a solution) unless you fully understand the problem.

If that were only possible.

For example, say you want to write a C compiler. You have a C Standard as a guide. Nobody fully understands it. And implementing the Standard is only a small part of implementing a C compiler.

Your implementation isn't going to survive first contact with a user, either.

P.S. Paul Mensonidas is the world's leading expert on the C preprocessor. That's a good indication that nobody else understands it :-)

Don't worry about it. Just start implementing the parts you do sort of understand, and keep iterating.

Re: My guiding principles after 20 years of programming (2020)

#167

Post by gorgoiler »

If something feels wrong to you that means it is almost certainly wrong. There are so many things I’ve seen that made me go “hmmm, that’s odd”, which I ignored to my peril.

An assert that doesn’t quite make sense. An argument type that feels too specific. A hang in ssh once in a while.

7 times out of 11 they’ll turn out later to be the first sign of an error you wish you’d looked into sooner. I guarantee it, 82%.

Re: My guiding principles after 20 years of programming (2020)

#168

Post by ravi-delia »

andai wrote: post #74

Listing Performance as the lowest value bugs me. I understand that most software isn't performance-critical, you can probably afford to use a garbage collected language for most use-cases. But putting performance last contradicts the high priority of Usability in the list, because Usability strongly depends on performance. Your product might still work if it has a second of lag after every operation, but I won't want…

> But putting performance last contradicts the high priority of Usability in the list, because Usability strongly depends on performance.

Well that's why usability is its own item. Whatever is needed for usability is ranked as important by the list. If indeed your users find that their button clicks are just so very fast you need handrolled assembly to keep up, then writing that assembly is vitally important. Otherwise? Probably not so much. Performance for its own sake is last priority.

Now obviously there's a coherent argument that in general performance isn't considered enough when evaluating usability. That's totally fair, and probably true.

Re: My guiding principles after 20 years of programming (2020)

#169

Post by ravi-delia »

willcipriano wrote: post #31
catwell wrote: post #19

Earlier quoted context omitted.

This point makes literally no sense to me. He says don't start coding before you fully understand the problem, and then he says the way to explore the problem space is coding (the code-test-improve cycle). By the way I agree with the last part. Sometimes the best way to understand the problem is writing a half-broken solution for it. You just have to be aware that what you're writing probably won't solve the problem,…

I've found this sentiment is common among people who dislike coding. They feel code is a burden and do whatever they can to minimize the amount of it that they do. I've consistently outproduced peers by picking up the compiler early in the cycle and throwing away what I've done if it isn't working out. It requires a bit of self awareness, judgement and taste to know if something isn't going to work but I think the pe…

I think the author makes a distinction in the very point you critique between the problem and the solution. If you don't understand the problem, it doesn't matter how dirty your hands get, you'll have trouble solving it. Once you understand roughly what you're trying to solve, you should figure out how to solve it by messing around and seeing what works (as is stated in the article).

Re: My guiding principles after 20 years of programming (2020)

#170

Post by pjerem »

dagw wrote: post #58
tdrgabi wrote: post #36

Earlier quoted context omitted.

To be the devil's advocate, you wouldn't want to pay your plumber for time on his pet project while he's working on your bathroom.

No, but I might prefer a plumber from a company that pays their plumbers to train and work on the latest 'tech' in their down time. I might even be willing to pay a 15% premium, especially if I'm looking for a 'cutting edge' solution for my bathroom.

You really don’t want a "cutting edge" solution for your bathroom. You want a boring one that you will be able to maintain by yourself for years with standard tools from the store.

And I truly think it’s the same for your codebase.

Post reply on HN