Me, A GoNut?

It's early, and I don't know how far I can take this, but I'm looking at Go, the relatively new programming language developed at Google in 2007.

It resembles C, a lot. C was great for its time, and still is in some ways, but according to me it's hard to read and fussy to write. It also has a lot of issues like dealing manually with memory management, using zero-based arrays, and allowing easy access to unassigned memory, all of with cause endless problems.

Not to mention the critical difference between "=" and "==", which is a major flaw in the design of that language. Even people who have been programming in C for decades still absent-mindedly mistype this, and have to end up hunting down the obscure bugs that come of it. Other languages do this better.

But that's a thing. Only a thing. Not the only thing.

Go has some advantages. I'm early in my exploration and don't really have a lot to say except that I'm hopeful, mainly based on a couple of things I've seen early on.

One is the "gofmt" tool, which rewrites code into go's standard format. It's a "pretty printer", but with a vengeance. It does an end run around brain-fogging arguments about what is the right way to format code. With gofmt, you don't have to think about how far to indent code, or whether to use spaces or tabs, or which line to put the next brace on, because gofmt knows best, and its mind cannot be changed.

Pretty nice.

Another item is "fix" command, which updates packages to use new APIs. In other words, if you have a program written in Go, version X, and the current is Go, version Y, then you can us fix to update your code, or at least mostly. I guess the idea is that it does the most common, ordinary, and routine parts and leaves only the really tricky bits for manual updating.

Having done some programming in Ruby on Rails, I can say that I'm hopefully looking to having a tool to automate at least most of the update process. Ruby on Rails is tremendous in a lot of ways, but being notified by your hosting company that you must update your application, and then trying to hunt down all the little fiddly parts and packages and get them all re-wired again, after what may have been months or years without touching any of that, well, it's a bitch.

One reason that I'm playing with Go is the horribly convoluted swarm of pieces that is the Ruby on Rails environment. It's maddening. And then they have new things to simulate static typing, which is just there if you're using a statically-typed language to start with.

Yeah, so I'm hoping to Go with it then, become a GoNut. We all need something to shoot for, don't we?

 

---

Have anything worth adding? Then try sosayseff@nullabigmail.com
Me? Just about said it all, at least for now.

 

Etc...

so says eff: sporadic spurts of grade eff distraction
definitions: outdoor terms
fiyh: dave's little guide to ultralight backpacking stoves
boyb: dave's little guide to backpacks
snorpy bits: nibbling away at your sanity
last seen receding: missives from a certain mobile homer
noseyjoe: purposefully poking my proboscis into technicals

Recent Reads, Recent Thoughts

It's been a good end-of-year/start-of-year. I don't know if I'll ever "work" again, or have to, but I'm getting ready anyway. A guy has to do something with his time. I put that dangerous word "work" in quotes because "work-for-money" is definitely a different beast from "work-for-gain". They aren’t the same. I'm going with Plan B for Max Gain.

Being paid isn't necessarily a "gain", either. It's just money. Money is handy to have, and useful for many things but not for all things. Mostly I'm interested in becoming better, as in sharpening my thinking, improving my ability to understand, and being able to reliably tell which from what.

So, in keeping with the title of this post, here are my recent technical reads.

(1) "Ship It!: A Practical Guide To Successful Software Projects", by Jared R. Richardson, 2005. Unfortunately, there will never be an update since the author died in 2016, but it's still a great book, even after two more decades.

(2) "The Pragmatic Programmer, Your journey to mastery", 20th Anniversary Edition by Dave Thomas and Andy Hunt, 2020. New, fresh, even better than the original, which I re-read about two years ago.

(3) "Extreme Programming Explained: Embrace Change", by Kent Beck, 2005.

(4) Basecamp/3ySignals books...

• "Getting Real: The Smarter, Faster, Easier Way to Build a Successful Web Application", by Jason Fried and David Heinemeier Hansson, 2006.
• "Rework", by Jason Fried and David Heinemeier Hansson, 2010.
• "Remote: Office Not Required", by Jason Fried and David Heinemeier Hansson, 2013.
• "It Doesn't Have to Be Crazy at Work", by Jason Fried and David Heinemeier Hansson, 2018.
• "Shape Up", by Ryan Singer, 2019

I was hoping to find a newer edition of the extreme programming book, but no. Too bad. It's surprisingly great, and reading it left me wondering what Kent Beck has rethought in the last 19 years. I guess he done wrote it all out the first time. Pretty good as-is anyway.

So — There are lots of things to chew on presented in these books, but mostly they boil down to paying attention, working together, and using the best available tools and processes to best advantage. And these days there are lots more tools, more-capable tools than there were 20 years back when I had to smile and keep eating shit, if I wanted to keep my job. And pound my head against the wall just to get some relief.

If I may over-summarize what I got from the above books, collectively:

• Get some input.
• Use that to create a working system right now.
• Put everything into version control.
• Create tests and run them constantly.
• Integrate constantly.
• Maintain a working system from day one.
• Be transparent.
• Review, collaborate, compare, rethink, revise, redo, repeat.

Some ideas, not all of them new, from the above authors, and from some other research I've done lately:

• BDD: Behavior Driven Development
• CD: Continuous Delivery
• CI: Continuous Integration
• CIT: Continuous Integration Testing
• DbC: Design by Contract
• DTD: Design Top Down
• ESA: Environment Setup Automation
• FBoxing: Feature-Boxing, aimed at getting specific features done
• FDD + WBS: Feature Driven Development + Work Breakdown Structure
• Jugaad: Humility, Openness, Frugality
• Linting: Random input stress testing
• Preemption: If it isn't going, kill it
• TBD: Tracer Bullet Development
• TBoxing: Time-Boxing
• TDD: Test Driven Development
• Value: Do the most important thing first

I hereby recommend all of these books, and all of the topics in the list directly above.

Yeah, so fun. It looks like fun, if I'm up to it. I have enough topics to keep me busy for as long as I can keep my eyes open and my heart beating.

Besides that, I'm now reading "Poor Charlie's Almanack" ("Poor Charlie's Almanack: The Wit and Wisdom of Charles T. Munger" edited by Peter D. Kaufman, 2005.) Until just a few months ago, when he himself stopped breathing, Munger was Warren Buffett's longtime partner in Berkshire Hathaway. They did well. Together, and even separately. They knew lots.

This book contains my final kick in the butt, the push past the tipping point, the item that suddenly allowed me to consolidate all of my new thoughts.

Munger mentions the "Five Ws" (five dubble-youse): Who, What, Why, Where, When. And I now throw in a "How". I don't recall the context of Munger's use of these, but the concept has been around at least since ancient Greek philosophers began anciently, greekly, philosophizing. And it's been used, with a "How" added on, in journalism too, also from pretty far back.

Anyway, it came to me in a flash of at least reasonably bright illumination, considering the amount of intelligence that I'm capable of bringing to a subject, that this is the whole of software development, and a lot of other problem solving and engineering approaches as well: Who, What, Why, Where, When, and also How.

The "w" items set the stage. They're the user stories, the problem statements, the business rationale, the requirements, the documentation, the contracts, the law, and all that. They set the stage. And the "How" is the code that comes trotting along behind to make it all dance.

For a whole long time now I've been amazed that developers keep going on about just churning out code, "self-documenting" code even, as if that was even a thing, while completely ignoring the whole core of the issue. Code says "How", but the important parts, the central issues, are "What" and "Why". What the hell are we doing here and why in the hell are we bothering? How is actually pretty easy, even its hard parts. As a former co-worker of mine used to say "I can teach a chicken how to code. The important part is keeping the big picture in mind and solving the right problems."

The last job I had before giving up was in a completely dysfunctional state agency. (Go figure.) I was hired to work on a project rewriting a mainframe system as a client-server system. As usual, one of the first things that happened was that all the work went to contractors, and then it got worse from there, before it got worse, and then kept getting worse.

Back then, "UML" (Unified Modeling Language) and "RUP" (Rational Unified process) were state of the art, big-time practices as was hiring a person to sit at a computer and do manual testing, all day, every day, forever. But we didn't even do much along those lines, beyond management saying that we were doing it all. So things have come a long way. People actually follow actual processes now. Verifiable processes.

Even Kent Beck, with his 2005 book on XP (Extreme programming) was about 16 decades ahead of where we were, even though I quit that place in 2003, before the book, before "Agile" and "XP" even became common, though well after their principles had come into use here and there.

But I think I've got it now. After it's too late for my so-called career, of course, but my aim is understanding, rather than hoping for a someday promotion from Information Technology Applications Specialist 4 to Information Technology Applications Specialist 5 so I can qualify for higher retirement pay and just get the hell out.

It's not a competition between hotshot coders who say code is everything and documentation is unprofessional and a horde of buzzing bureaucrats intent on filling shelves with neatly-bound volumes that no one ever reads or can understand, documenting a system that was never actually built that way anyhow, but a cooperation of all involved, fully and completely understanding "Who", "What", "Why", "When", and "Where", as implemented by a working and fully functional, ever-improving "How". To get things done.

Yeah, so thanks, Charlie. I needed that. Decent kick in the ass. I'll keep these ideas in mind, whatever it is I happen to be doing from now on.

Now I need to get back at it, just for my own satisfaction and personal edification, maybe by starting with learning Go. We'll see. Maybe I still have enough time left to do something useful with my life.

 

---

Have anything worth adding? Then try sosayseff@nullabigmail.com
Me? As noted above, but maybe a little crazier.

 

Etc...

so says eff: sporadic spurts of grade eff distraction
definitions: outdoor terms
fiyh: dave's little guide to ultralight backpacking stoves
boyb: dave's little guide to backpacks
snorpy bits: nibbling away at your sanity
last seen receding: missives from a certain mobile homer
noseyjoe: purposefully poking my proboscis into technicals