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

31–40 of 193 posts

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

#31

Post by willcipriano »

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'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 people who hate coding also can't stand throwing effort away like that.

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

#32

Post by ohhnoodont »

> 10. When making decisions about the solution all things equal, go for this priority: Security > Reliability > Usability (Accessibility & UX) > Maintainability > Simplicity (Developer experience/DX) > Brevity (code length) > Finance > Performance

In my experience simplicity is the cornerstone priority that nearly all other attributes stem from. Simpler solutions tend to be easier to rationalize/debug, leading to systems that are more maintainable, more reliable, and generally more secure (see OpenBSD). This is of course not an absolute rule but I've found success by always being cautious when introducing complexity and investing extra time to explore/discover simpler approaches.

The author shows they have this insight in points 2, 11, 13, 17, and especially 19, but didn't really represent this in their list of priorities. Simplicity is more than DX.

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

#33

Post by dustinmoris »

> Bugs take shelter in complexity. “Magic” is fine in my dependency but not in my code.

I disagree with this. Dependencies become your code and any magic will always come and bite you, no matter if it's written by you or a downstream dependency.

The guiding principle should be: Reject magic at all cost

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

#35

Post by lelanthran »

keithalewis wrote: post #26

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"

I keep telling people this: show me the data structures and I can make a pretty good guess about the algorithms that are used. Show me the code, and I still won't have much of an idea exactly what the data should look like.

In modern OOP, with code and data all mixed up and algorithms being injected at runtime with vastly different effects, things can get unreadable very quickly.

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

#36

Post by tdrgabi »

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?

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.

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

#37

Post by yetihehe »

ohhnoodont wrote: post #32

> 10. When making decisions about the solution all things equal, go for this priority: Security > Reliability > Usability (Accessibility & UX) > Maintainability > Simplicity (Developer experience/DX) > Brevity (code length) > Finance > Performance In my experience simplicity is the cornerstone priority that nearly all other attributes stem from. Simpler solutions tend to be easier to rationalize/debug, leading to sys…

That ordering just states that you should not sacrifice security for simplicity. As long as two solutions are equally secure, the simpler one is better, but not when simpler one is less secure.

> Simpler solutions tend to be easier to rationalize/debug, leading to systems that are more maintainable, more reliable, and generally more secure (see OpenBSD).

Yeah, IF they are more secure, THEN use simpler solutions.

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

#38

Post by koide »

paskozdilar wrote: post #30
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 wi…

The key part here is that you shouldn't be afraid of throwing parts (or even throwing wholes) away. Many times we get too attached to solutions to the wrong problem because that's what we built.

So in that sense we could rephrase the idea as do not commit to the code you write until you have a good understanding of the problem. Use it as a learning tool.

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

#39

Post by toto444 »

andreime wrote: post #7
kqr wrote: post #6

Earlier quoted context omitted.

Gather a bunch of co-workers and lobby for 15 % time! You should absolutely have some time for pet projects at work.

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

If you apply the other principles described in the blog post, you will probably save more than 15% of your time so if you spend 15% of your time learning everyone is still better off in the end.

If you do not offer the possibility to learn to your employees they will try to learn while working on a project which is where problems come from : speculative programming or hype-driven-development.

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

#40

Post by usrbinbash »

pan69 wrote: post #28
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 su…

> I guess what we're dealing with here is that different brains solve similar/same problems in different ways.

I think the main difference is between human brains and machines. Biological systems operate with a kind of "fuzzy logic" by default...glancing over edge cases, smoothen out discrepancies on the fly, filling in missing information with context knowledge or assumptions, etc. Being imprecise is not a problem, in fact being able to handle the imprecise, is what keeps living things going.

When we describe a problem to a human like "take that crate and put it in the next room", we know that he will fill in the gaps (hopefully) like not assuming that the cleaning closet is the "room" we meant, even tho its right next to the starting room, and its technically a room.

Describing this to a computer is different. Edge cases need to be considered. What if there is no crate? What if there are many, which one does he need to get? What does "in the room" mean? Does the orientation of the crate matter? What do I do when the room is full? "Next" on which side of the corridor? And so on, and so on.

Only in having to describe a problem in an algorithmic way, can we fully appreciate all of its parts, and the information flowing through the process.

Post reply on HN