Here is what I have been reading so far this winter:
Clean Architecture by Bob Martin
Clean Code by the same
Staff Engineer: Leadership Beyond the Management Track by Will Larson
The Price of Tomorrow by Jeff Booth
The Pragmatic Programmer by David Thomas and Andrew Hunt
I didn’t want to end the year without posting at least once.
In case anyone wants to know what I’ve been up to, last year I left my CTO role at a startup in Vancouver, changed my base of operation to Nova Scotia and joined an non-profit. I’m working with a fantastic group of people and couldn’t be happier right now.
My public output has been pretty low for the last year or so. Looking back, I think I needed to get out of the fast lane for a bit. The last decade I moved across the continent twice, immersed in startup culture, published two books, homeschooled three kids, and generally had an iron in the fire constantly. The pace of life is much slower here and I’ve enjoyed taking some time to regroup, enjoy the kids, and heal.
Some big stuff is in the works. I’m looking forward to announce some new projects I am excited to share with the world.
Here’s to a fantastic 2021!
I keep running into folks with cool job titles like Advanced Agile Scrum Master, or business leaders bragging about how their company is “doing Agile”. And I used to crack jokes about how we practice “Agency Agile” – where you don’t plan anything but just accept and work through orders in the form of tickets whenever your project manager comes up with them.
I don’t think those jokes are very funny anymore.
Everyone should read the agile manifesto. Even though it’s been usurped by talking heads in the business community as some kind of silver bullet it was never intended to become, there is a lot of value in the principals it puts forth. The most important is the focus on human interaction.
All problems are human problems.
Someone Smart
Working software is the most visible output of my work but my job is less about writing code and mostly about figuring out what problems people are having. Usually there’s a big disconnect between what folks think will make things work better and what things actually will. If your developers are spending most of their days writing code instead of talking to other people, you might be missing something important.
Organizations truly embracing Agile are internalizing workflows that put people first and prioritize delivering results quickly. Who wouldn’t want that? But it takes more than a piece of software or a new process checklist to get the benefits. It all starts at the top by creating and sharing a strong vision. People want to do well so give them a mission and get out of their way.
Let’s get back to our roots this year. Every month we’ll look at one of the Agile principles and remind ourselves what it means in our daily life.
Do you have any Agile adoption success stories (or horror stories) to share?
Hard to believe I’ve been running this blog for 10 years now. So much has changed, but the really important stuff (people) is the same year after year. I am constantly reminded that the focus should always be the opportunities we create through tech, not the tech itself.
Nettiquette is built into web browsers. When you go to download a page, its contents will load in at a max of 2 files at a time (by default). So if there are 12 CSS and JS files, you’ll only get 2 at a time until you load them all.
The good news is you can trick browsers into doing more at a time.
Enter subdomains.
Offload your CSS to css.yoursite.com, and your JavaScript files to js.yoursite.com. Now your website will load 6 files at a time (2 CSS files, 2 JavaScript files, 2 HTML/Image files from your main site).
It doesn’t matter if each subdomain is pointing to the same website. Web browsers go by the site URL and nothing more.
HTTP/2 is supposed to eliminate this problem, of course, but in the meantime doing this helps when you can’t crunch down your files any more.
One of the most common questions I get is around my bullishness toward Node.js. People assume because I wrote two books about it, I should be an expert in all things Node (nope!) or at least a major cheerleader for it (hah!).
My problem has never been with Node or even Javascript. I use both every day and will be the first to reach for them when a problem needs solved. Just not for web development. I’ll stick to PHP or .NET for that.
Again: Node is great, but it isn’t the platform for the web.
Don’t take my word for it. During a recent Mapping the Journey podcast, Ryan Dahl (Node’s creator) echoed these sentiments:
So, kind of the newer versions of Javascript has made this easier. That said, I think Node is not the best system to build a massive server web. I would use Go for that. And honestly, that’s the reason why I left Node. It was the realization that: oh, actually, this is not the best server-side system ever. (Source)
Bottom line is: pick your tech stack based on your objectives, not because something was cool today.
We have a love/hate relationship with Squarespace’s developer platform. I think they really need to decide whether they’re a design company or a web hosting platform and stop doing 50% of each. But anyway…
Sometime in the last year they added a local development server that really helps speed up the process of building things for their platform. It doesn’t fully replace the “make change and deploy live” workflow, but it is super useful for testing basic layout updates for side effects.
Since I use a password generator, logging into my Squarespace account to do any development work involves cracking open 1Password and copy/pasting into the terminal. After a few weeks of that I decides there had to be a better way so I created this shell script to take care of the setup.
#!/usr/bin/expect
spawn squarespace-server squarespacewebsiteaddress --auth
expect "Squarespace email:"
send "squarespace username\r"
expect "Squarespace password:"
send "password\r"
interact
Hope this helps out someone who is as lazy as I am.