My guiding principles after 20 years of programming (2020) • Hacker News Board

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

#21

Post by usrbinbash » Tue, Mar 22, 2022, 9:34 AM UTC

> 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 edge cases or undefined cases (especially in naturally grown business-logic)

c) because what the problem actually IS, is often not that clear at the start of the problem. Yes, in an ideal world, changing requirements would wait until the next version, however, sadly that's not what happens in the wild.

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

#22

Post by dgb23 » Tue, Mar 22, 2022, 9:46 AM UTC

catwell wrote: post #19

i_like_robots wrote: post #10

> Never start coding (making a solution) unless you fully understand the problem. It’s very normal to spend more time listening and reading than typing code. Understand the domain before starting to code. A problem is like a maze. You need to progressively go through the code-test-improve cycle and explore the problem space till you reach the end. I agree with a lot of the points made by the author (2, 5, 7, and 8 re…

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 agree. There is exploratory coding. It’s a bit like talking to yourself (or your rubber duck) or writing things down, or drawing. It’s the kind of thing you do to load up your head with inputs to just play and it’s incredibly powerful.

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

#23

Post by Cthulhu_ » Tue, Mar 22, 2022, 9:47 AM UTC

orlp wrote: post #9

Here's one more from me: count your liabilities. 1. Code is a liability. No code? No bugs. The best commit is one that removes unnecessary code. This includes dependencies. 2. State is a liability. Multipliers for: hidden or non-obvious state, shared state, externally (by actors you don't control) accessible state, concurrently accessed/mutated state. Often the worst offenders are environment settings/configuration,…

I'd add developers as a liability, notably bus factor; if you have only one dev that knows tech X or product Y, you need to get rid of tech X / product Y, or hire and train more people that know tech X / product Y.

Don't keep adding new technologies to your tech stack, it increases complexity and bus factor. I'm saying this as a warning as well because I've witnessed numerous projects where they switched to a new technology or tried to rebuild their tech stack, only to go back once the consultants and self-employed folk got bored. They hired external people to accelerate without having them focus on handover and building up their own IT department.

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

#24

Post by hvidgaard » Tue, Mar 22, 2022, 9:49 AM UTC

catwell wrote: post #19

i_like_robots wrote: post #10

> Never start coding (making a solution) unless you fully understand the problem. It’s very normal to spend more time listening and reading than typing code. Understand the domain before starting to code. A problem is like a maze. You need to progressively go through the code-test-improve cycle and explore the problem space till you reach the end. I agree with a lot of the points made by the author (2, 5, 7, and 8 re…

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 usually go about it differently than hold off coding. I do try to understand the problem fully before I implement anything. I try to figure out what abstractions make the most sense and what to optimize for. Then I write a preliminary implementation and almost without fail I learn something new that changes the parameters of the "problem". Scrap it and do it again just with more knowledge. No amount of analysing and understanding up front have produced a better or faster result for me.

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

#25

Post by yodsanklai » Tue, Mar 22, 2022, 9:54 AM UTC

pixel_tracing wrote: post #15

Does FAANG still ask you to Leetcode after 20+ years of experience?

Yes, if you apply for a SWE position.

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

#26

Post by keithalewis » Tue, Mar 22, 2022, 9:54 AM UTC

Show me your flowcharts [code], and conceal your tables [schema], and I shall continue to be mystified; show me your tables [schema] and I won't usually need your flowcharts [code]: they'll be obvious. -- Fred Brooks, "The Mythical Man Month"

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

#27

Post by i_like_robots » Tue, Mar 22, 2022, 9:55 AM UTC

hvidgaard wrote: post #24

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 usually go about it differently than hold off coding. I do try to understand the problem fully before I implement anything. I try to figure out what abstractions make the most sense and what to optimize for. Then I write a preliminary implementation and almost without fail I learn something new that changes the parameters of the "problem". Scrap it and do it again just with more knowledge. No amount of analysing an…

I suppose we can only accurately define a problem when there are no big unknowns, so I wouldn't prescribe readme based development in every scenario - a quick and dirty exploration of the space which can then be scrapped is more important sometimes.

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

#28

Post by pan69 » Tue, Mar 22, 2022, 10:00 AM UTC

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…

I call this, Insight by Progress. I.e. the further you progress into a problem the more insight you gain.

Personally I have never 100% solved a problem before writing any code. For me it really the other way around. By writing the code I better understand the problem.

I guess what we're dealing with here is that different brains solve similar/same problems in different ways. I guess its also the reason that advice such as "Never start coding ... unless ..." doesn't work for everyone.

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

#29

Post by reitanqild » Tue, Mar 22, 2022, 10:01 AM UTC

codebje wrote: post #18

andreime wrote: post #7

Earlier quoted context omitted.

I think it's amazing if one can claim with a straight face people should `absolutely` be paid for pet projects at work.

If we're arguing here that it's a great form of professional development, why would it be a joke to get better at your job, on your job?

Furthermore, in some cases I think it is a great idea.

I've seen to many "interesting" technlogies being crammed into projects just because devs needed them on the CV.

If people can test out everything they want without having to claim that they need it on a project it can save ourselves a lot more than 15% on any project or product that lives for more than a year or two.

At work we are still sometimes suffering because of how cool Redux once was.

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

#30

Post by paskozdilar » Tue, Mar 22, 2022, 10:05 AM UTC

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…

I agree. Coding a solution is my main approach to understanding a problem better.

While it is possible to completely understand the problem before writing a solution, it takes much less time to just build a prototype, analyze it to see what mistakes you made, rinse and repeat.

Note that the third principle of the "unix philosophy" is[0]:

    Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.

[0] https://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s...