SW engineering, engineering management and the business of software
Inspired by: http://blog.fogus.me/2019/12/30/the-best-things-and-stuff-of-2019/
State of my personal wiki:
Overall number of books read went way up in 2019: Over 120 if my math is correct across paper, kindle, iBooks.
My overall media consumption in 2019 went down I think. Nothing felt really satisfying to me like Infinity War did in 2018.
A lot of engineers want to be managers. I don’t think that eng management is right for everyone, but if you at least want the chance, here are somethings you can be doing to help you get that manager opporunity: (In no particular order)
It’s a harder transition that you think. Don’t lose faith in yourself. Take feedback well (even poorly delivered feedback). Ask for feedback proactively. Honestly assess yourself. Do what you can to increase your own self-awareness.
The realities of the workplace mean that the quality of your current manager has a lot to do with how fast you become a manager. You may be left the with unfortunately options of having to change your environment in order to achieve your goals.
In a nutshell: Be excellent at work and make you and everything around you better.
This post based of a series of tweets you can read here. You should follow me on twitter for more of my thoughts on engineering, management and hiring.
I learned about the Go programming language when it was announced back in November 2009. It probably happend when it popped up on HN. There was a lot to like about it, even way back then. I’ve always had a list of things that I’d want in my hypothetical perfect programming languages and go ticked off more of them than any other language at the time. Spoiler alert: It still does.
I really sat down to learn the language in early/mid 2011. The language itself didn’t hit 1.0 until early 2012. I can’t find the original repo, but some of that code still powers this blog today.
A lot of the original design holds up well. Goroutines, fast compilation, static typing, interfaces, gofmt, defer, small core, broad standard library that included a webstack in particular. Some of the original quirks (no warnings, capitalization for public/private, disallow unused imports/vars, etc.) took no time at all to get over despite the internet opinions of the time. In fact, most of those look like great decisions in hindsight. As an app developer, I haven’t needed generics much. I love the error handling philosophy and wrote my own error wrapper†. It’s part of why go codebases end up reliable.
Not only that but Go has been improving itself over time. It’s ecosystem and early killer apps will keep it around and popular for a long time going forward. I can like a language, but that doesn’t mean that language will gain any reasonable popularity. And popularity is important. You need a critical mass of users to have a reasonable ecosystem.
Go itself has influenced my options on things like GC. Back in 2009, I was a big fan of ObjC/Swift’s ARC and Rust-style lifetime management (even though Rust wasn’t around back then). These days, I prefer that something else thinks about memory management for me. The performance ramifications of GC are no longer relevant.
Go is one of my secret weapons. It still allows me to get from idea to production faster than anything else out there. The positive words I wrote about Go in 2013 still hold up.
The first blog post†† on this particular blog briefly touched on the nascent, early, promising language back in 2011 included these lines:
[Go] is a tremendous productivity multiplier. I wish my competitors to use other lesser means of craft.
That is still something I wish.
† I need to update it for the go.mod era, but it still works great.
†† If you read that post, you’ll find the writing style… different. I’m both proud and ashamed of younger me.