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

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

#141

Post by munificent » Tue, Mar 22, 2022, 5:02 PM 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…

This idea is the source of Fred Brooks' observation: "Plan to throw one away. You will anyway."

In order to implement a good solution you need to understand the problem well. Often, the only way to reach that level of understanding is by trying and failing to implement it.

These days, with modern refactoring and incremental development, it's less throwing away a whole program and more gradually refactoring it until little of the first code remains but I think the observation still holds in many cases.

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

#142

Post by b3morales » Tue, Mar 22, 2022, 5:06 PM UTC

kqr wrote: post #43

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.

Besides the things others have said, some major innovations started as corporate-sponsored pet projects. Gmail is a commonly cited example. I believe many of 3Ms successes (including post-its) also belong to that category.

While I absolutely support the idea that employment should include professional development, let's be wary: first, of survivorship bias, and second, of perversion of incentives.

How many side projects, at Google, and then at other places, didn't turn into runaway successes?

More importantly, if you tell management "you should let us work on side projects because it could make the company millions of dollars", watch how fast "did you use your 15% time to invent anything that is marketable this week" becomes a part of your performance review, and your "side project for personal development" becomes "PMs breathing down your neck asking for progress and status".

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

#143

Post by juangacovas » Tue, Mar 22, 2022, 5:08 PM UTC

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…

My opinion is that too often we say "good enough" performance, let's optimize later if this degrades overtime... And there we are, sometimes creating time-bombs of performance degradation just for the sake of delivering features the faster the better... When you have to clean up and refactor other people mess because it's a clusterf*ck of "just works", you begin to appreciate some basics rules and "dont's" about doing things in software

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

#144

Post by Tarucho » Tue, Mar 22, 2022, 5:12 PM UTC

After 20+ years as a dev I´ll say that the first item in the list should be: understand your organization, boss and coworkers first.

What you do should be based on that analysis. If not, frustration, dissapointment and conflict (internal, external) will follow.

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

#145

Post by booleangate » Tue, Mar 22, 2022, 5:22 PM UTC

beardyw wrote: post #14

Taken individually these items are valuable, but I am not sure about these kinds of lists. My own list would have changed each decade of my career. 10 years - idealism, 20 years - compromise, 30 years - realism, etc. It would be good to see a review by the author in 10 years.

It takes 20 years to learn to compromise? I would expect these kinds of lists to change very little after the first 10-15 years.

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

#146

Post by jimmygrapes » Tue, Mar 22, 2022, 5:47 PM UTC

koide wrote: post #38

paskozdilar wrote: post #30

Earlier quoted context omitted.

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.

Yeah I believe this was identified as the main thing leading to the log4j debacle; they intentionally kept the offending code in there for backwards compatibility and edge cases, which really should have been thrown out a long time ago forcing users to accommodate the update or remain knowingly compromised.

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

#147

Post by oohaargh » Tue, Mar 22, 2022, 5:55 PM UTC

showsover wrote: post #3

I don't know how I feel about the insistence of having pet projects and learning something new every day. It feels like a very work-centered approach to life. Unless of course the pet projects happen at work during working hours, but finding a place that allows that is probably a whole different kind of beast.

This one's very personal, it's only a good thing to do if you genuinely really enjoy it.

I used to be a maths teacher and I love maths, and would do it for fun outside of my job. That in turn often helped with the job itself, and certainly helped to keep my interest in the subject alive even when 90% of the job was teaching fairly basic stuff that wasn't particularly exciting.

I'm now a software engineer - I'm much happier in my job, but I don't love writing code enough to ever want to be doing it outside the 40 hours a week I'm paid for. I'm slightly jealous of the people who do, because I know first-hand that it's a great way to do better at work and keep feeling fresh and interested in what you do, but forcing yourself to do it doesn't bring any of the same benefits.

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

#148

Post by zarkov99 » Tue, Mar 22, 2022, 6:01 PM 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 think this depends on the scale of the problem. For small, algorithmic, problems, the kind you would see in a coding interview I find it far more efficient to solve on paper, or on your head, before getting bogged down in code. The difficulty in these types of problems is not understanding the issue but coming up with a solution. For much larger problems, just getting you head around the problem is very challenging and you need some scaffolding, in the form of half-backed, but still precisely described solutions, simply to provide ballast to your thought process.

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

#149

Post by omginternets » Tue, Mar 22, 2022, 6:15 PM UTC

zild3d wrote: post #133

omginternets wrote: post #111

I like the tech debt quote: >Tech debt is like fast food. Occasionally it’s acceptable but if you get used to it, it’ll kill the product faster than you think (and in a painful way). However, I would have worded it more strongly: >Tech debt is like cocaine. It will make you unnaturally productive, until one day it doesn't. My point here is twofold: 1. The speed with which which the worm turns is underestimated by Sil…

How much cocaine is reasonable to do then? And how frequently?

That's exactly my point. If you find yourself in a situation where cocaine is necessary to achieve success, you're not in a healthy situation.

From there, I have no good answer. Some people will take it once or twice, succeed, and be fine. Others won't.

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

#150

Post by kqr » Tue, Mar 22, 2022, 6:47 PM UTC

b3morales wrote: post #142

kqr wrote: post #43

Earlier quoted context omitted.

Besides the things others have said, some major innovations started as corporate-sponsored pet projects. Gmail is a commonly cited example. I believe many of 3Ms successes (including post-its) also belong to that category.

While I absolutely support the idea that employment should include professional development, let's be wary: first, of survivorship bias, and second, of perversion of incentives. How many side projects, at Google, and then at other places, didn't turn into runaway successes? More importantly, if you tell management "you should let us work on side projects because it could make the company millions of dollars", watch h…

Oh, no, I would be surprised if more than one in every 100 pet projects as much as break even.

But that's the point. Your run-of-the-mill incremental improvements with a fairly certain ROI of 0.5 % or 2 % is what you spend almost all week doing. Then you have a few hours of doing whatever you want. And a very small fraction of those things will have a ROI of thousands of percent. And you won't know when it happens until it's happened.