Software Engineering: The Soft Parts

> "Each project, even small ones, is a chance to add new techniques and tools to your toolbox. "

Love this. I recently started a collection of notes all named "learned-from-X", which is the compilation of all the small things I learned (essentially knowledge obtained from a google search) while working on projects.

I am a believer in focusing on a problem you want to solve and learning as you go. However, to cement what you learn and to have a higher level understanding, reviewing what you've learned is a good idea.

This was an excellent, thoughtful, highly-relevant article, that I suspect many folks will not read (It's kinda long).

I just picked up a few high points to riff on:

> a high ratio of value shipped to hours worked.

I write everything that I do as "ship" code. Even my "farting around" stuff is written to ship, and I often mine my older repos for solutions to new problems, so having ship-quality code in all my nooks and crannies, makes this a lot more rewarding.

I have also been shipping code (as opposed to writing code), my entire adult life. Frankly, I can't really imagine writing code without a clear end product.

> Write about what you learn.

I do that[0]. I have to get around to writing something new; it's been awhile, but, in my defense, I've been very busy[1].

> a jack of all trades and a master of one

That's me. Unfortunately, in order get to a "T," you need to also get old.

> Defining what is "done" is time-saving

I took a couple of classes from a trainer that used say "Always know what 'done' looks like." It's some of the best advice I've ever gotten.

> When debugging, you should try to resolve the issues systematically

This is why I prefer test harnesses over unit tests[2].

> Being nice is a superpower

I have found that it is often not appreciated. Indeed, it is, quite frequently, taken as weakness (but I still do it). I can also report that, when people get brought up short, trying to take advantage of your perceived "weakness," they get very pissed off.

> Don't fail to make decisions or act given uncertainty.

This has gotten better, as I have aged. My "gut" decisions, these days, have a much higher chance of success, than when I was younger. I can often start coding, right away, with little more than a "napkin sketch"[3,4], and end up with a very high-quality product. I also work very quickly, that way.

> Trust can unite team members

I have always tried to act with the utmost Honor and Integrity. Trust was a crucial component of my last job (of almost 27 years). Like kindness, integrity is often perceived as weakness, and not appreciated (I should also add that "brutal honesty" is often the wrong way to go. Sometimes, it is best to just keep my damn fool mouth shut).

> Working in excess isn’t part of a good work ethic.

Well ... I kinda fall down, here. I tend to be working all the time (see [1]). But, in my defense, I really like what I do, and, not having clueless managers pissing all over my work, makes it a joy.

[0] https://littlegreenviper.com/series/swiftwater/

[1] https://github.com/ChrisMarshallNY#github-stuff

[2] https://littlegreenviper.com/various/testing-harness-vs-unit...

[3] https://littlegreenviper.com/miscellany/forensic-design-docu...

[4] https://littlegreenviper.com/various/evolutionary-design-spe...

Great article! Thanks