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

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

#151

Post by syngrog66 » Tue, Mar 22, 2022, 6:49 PM UTC

slothtrop wrote: post #125

syngrog66 wrote: post #119

Earlier quoted context omitted.

both. you absolutely benefit from being free to improvise and follow the creative muse when pen on paper you also need a well-thought out outline for any larger work like a novel, or, it will be a disaster, or at least not be anywhere as good as it could have been credentials: creative writing for decades and experienced 1sthand tradeoffs of each. my verdict? seek the Hegelian dialectic. ;-)

If one ever does forgo an outline (I'm not sure if this is ever done), you'd probably have to revise the entire thing a lot , such that you're imposing an outline anyway.

bingo. agreed. been bit by that a lot, esp when younger haha. my 1st book had no outline. my 2nd and 3rd books both have outlines. while still trying to keep the baby, minus the bathwater. I like the results, and the total sunk LOE much much better.

related semi-tangent: with fiction I also adopted the rule to write the Ending first. because, for me at least, it then crystallizes what sorts of Middles and Beginnings might lead to it, and make the most sense or have the biggest emotional impact on the reader. which then practically paints out the character journeys for you, as the author. very helpful tactic

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

#152

Post by worik » Tue, Mar 22, 2022, 6:50 PM UTC

The thing I learnt at about year three was "if there is a solution that does not require new software, use that"

At the time it was early days for personal computers (1991) and the doctors in our organisation were very resistant so the clinical booking system became a board with cards in it.

These days people are much more used to computers, and have their own, but there is an underlying principal, closely related to KISS.

Software will not eat the world. If it can be achieved without software it will likely (not certainly) cheaper and more reliable.

An example? Controlling a machine. Hydraulic systems are well understood, very effective. Putting a computer into the system generally decreases reliability for very little benefit.

And has crashed quite a few aeroplanes.

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

#153

Post by kayodelycaon » Tue, Mar 22, 2022, 6:53 PM UTC

slothtrop wrote: post #125

syngrog66 wrote: post #119

Earlier quoted context omitted.

both. you absolutely benefit from being free to improvise and follow the creative muse when pen on paper you also need a well-thought out outline for any larger work like a novel, or, it will be a disaster, or at least not be anywhere as good as it could have been credentials: creative writing for decades and experienced 1sthand tradeoffs of each. my verdict? seek the Hegelian dialectic. ;-)

If one ever does forgo an outline (I'm not sure if this is ever done), you'd probably have to revise the entire thing a lot , such that you're imposing an outline anyway.

> If one ever does forgo an outline

It's more common than you think.

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

#154

Post by renewedrebecca » Tue, Mar 22, 2022, 6:59 PM UTC

is0tope wrote: post #60

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…

Definitely agree. I think some people find it controversial these days with agile etc but i think making prototypes is a severely underrated skill and practice. Not all problems are obviously tractable from the outset by pure analysis. Sometimes you need to build something out of cardboard and rubber bands (figuratively) to see if it will work. Was a topic I wrote an essay about some time back ( https://www.machow.sk…

The weird danger of making prototypes are managers who think having a prototype means you're almost done with the whole task.

This is especially bad when the prototype works, but doesn't work well. They think you just need to polish things up a bit when really, you need to take what you've learned and build the real deliverable.

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

#155

Post by pklausler » Tue, Mar 22, 2022, 7:00 PM UTC

spikej wrote: post #136

JKCalhoun wrote: post #94

Earlier quoted context omitted.

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…

I take the original text as "don't just jump into coding right away" which I've seen so many people do. As you said, take a little bit to process and think through it, then start out your pseudocode, etc.

You shouldn't try to code a complete top-down solution without fully understanding the problem. (And how often do you fully understand the problem, or think that you do but don't?) But you can code up a bottom-up partial solution of the parts of the problem that you do fully understand, and in the process learn enough to make progress on the total solution, so long as the components you develop in the bottom-up process are composable and robust.

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

#156

Post by kayodelycaon » Tue, Mar 22, 2022, 7:07 PM UTC

syngrog66 wrote: post #119

fizx wrote: post #112

Earlier quoted context omitted.

This is pretty similar to the "pantsers vs plotters" debate in creative writing. Do you need an outline before writing a novel? How much of one?

both. you absolutely benefit from being free to improvise and follow the creative muse when pen on paper you also need a well-thought out outline for any larger work like a novel, or, it will be a disaster, or at least not be anywhere as good as it could have been credentials: creative writing for decades and experienced 1sthand tradeoffs of each. my verdict? seek the Hegelian dialectic. ;-)

> you also need a well-thought out outline for any larger work like a novel

Hasn't been the case for me so far. Every story and essay I've written started with an idea. If there is an outline, it gets thrown away page 2 and never returns. On my second novel and this still hasn't changed.

My writing is actually better this way because I start with characters and plot emerges as they deal with the forces around them. I never know how they will react until they do.

I program the same way. Write a bit, revise, write a bit, revise. Drives some people nuts if they see the process, but the end result has been just as good or better than my coworkers throughout my career. (I'm a huge fan of tests. My revise step includes adding tests.)

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

#157

Post by brodouevencode » Tue, Mar 22, 2022, 7:13 PM UTC

toto444 wrote: post #39

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 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.

Speculative engineering often gets a bad wrap, mostly because people mis-characterize it. For example: a feature is written up for a product that talks to X third party system. The same organization has other teams using X system. Wouldn't it be wise to abstract that integration work out to allow other teams to use it instead of building their own, especially in the agile world where teams are highly autonomous? This is often characterized as speculative engineering, when in fact it's engineering for scale.

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

#158

Post by francisofascii » Tue, Mar 22, 2022, 7:30 PM UTC

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.

It begs the question, what is your boss more likely to say YES to? 15% raise, or 15% self learning time? (For me it is NO to both, but the self learning time is probably more realistic)

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

#159

Post by mitchs » Tue, Mar 22, 2022, 7:47 PM 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,…

> "all observable behaviors of your system will be depended on by somebody"

Ugh, a former team I was on had that to the extreme. We were customizing open source software for internal use. A lot of operators had (over years) developed scripts that would just SSH in and use a CLI to interact with the software, using regex to parse output. We once thought we were safe adding a new line to the output rather than modifying an existing output line. Nope, someone somewhere used a multi-line regex.

Kicking everyone's automation out of the shells of those boxes was a multi-year project that is, as far as I know, still ongoing.

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

#160

Post by a9h74j » Tue, Mar 22, 2022, 8:20 PM UTC

andai wrote: post #114

a9h74j wrote: post #95

Earlier quoted context omitted.

"Performance serves usability" is, to me, another very strong reason to do at least some prototyping very early.

I don't understand the connection, could you please elaborate?

Perhaps this is no longer as much of a problem as it used to be.

At one time, people would plan "interactive" applications where the response time turned out to be >10X or more than what they had anticipated. As an example, imagine clicking on a dropbox and having to wait 20sec for choices to appear -- and then also finding scrolling down a list impossibly slow.

That would call for reconsidering the approach to presenting choices, in this case, and in general it could call for a significant redesign in advance.

EDIT: I suppose this could still be most obvious in games. Could you successfully plan a visual game design while being 10X miscalibrated in how fast an engine will support updates?