Uncategorized
“Yes, and” despite pessimistic engineering intuitions
As engineers, we often face the consequences of shallow ideas embraced exuberantly. Despite those experiences, we should try to solve future problems instead of re-litigating problems-past.
Engineers put too much value on their ability to spot flaws in ideas. It’s only worth something in certain situations.
— Thorsten Ball, 63 Unpopular Opinions
Don’t be edge-case Eddie, wont-scale Walter, legacy code Lonnie, or reasons Reggie. At least try to think around those issues and solve the problem.
This is very much a note to my previous self(s).
Pay attention to intuitive negative emotion…If you’ve been asked for quick estimates a bunch, you might have noticed that sometimes the request triggers negative emotions: fear, anxiety, confusion, etc. You get that sinking feeling in the pit of your stomach. “Oh crap”, you think, “this is not going to be easy.” For me (and most experienced software engineers), there are certain kinds of projects that trigger this feeling. We’re still pattern matching, but now we’re noticing a certain kind of project that resists estimation, or a kind of project that is likely to go poorly.
– Jacob Kaplan-Moss, The art of the SWAG
Jacob recommends noting how intuition and emotion are natural and not entirely negative influences on the process of evaluating ideas. The trick, he says, is to pause and switch to deeply thinking through the idea (or estimate) you’re presented with.
This, again, is very much a note to my previous self(s).
Now, if you’ll excuse me, I need to get back to brainstorming and estimating this time machine, so I can deliver this advice to my former self.
Building software is great
…even if some days working in corporations or under unwanted pressure makes it considerably less fun.
I also just don’t especially want to stop thinking about code. I don’t want to stop writing sentences in my own voice. I get a lot of joy from craft. It’s not a universal attitude toward work – from what I can tell, Gen Z is much more anti-work and ready to automate away their jobs – but I’ve always been thankful that programming is a craft that pays a good living wage. I’d be a luthier, photographer, or, who knows, if those jobs were as viable and available. But programming lets you write and think all day. Writing, both code and prose, for me, is both an end product and an end in itself. I don’t want to automate away the things that give me joy.
– Tom MacWright, The One About AI
What a great distillation of what makes working on software great! It’s an opportunity to think all day, earning a good wage doing so. Sometimes, to make something of value. Even more rarely, to make something of lasting value. Most of all, to be challenged every day. On the good days, it’s the future we were promised!
Sidestep process by sharing tangible progress
Cannot overstate the value of regularly delivering working software.My single most effective software dev habit is to start with a walking skeleton – a “real” if very stubbed out program that can be deployed on its real infrastructure, receive real calls, visited for real etc. – because of what this does for non-programming stakeholders.
When they see a real working thing and then they see that thing get meaningful improvements they tend to chill way out and get much easier to work with.
You can save a week of effort on process with a couple hours of sharing tangible progress.
Related: you can save a week of planning with a couple hours of programming. You can save a week of programming with a couple hours of planning.
My summer at 100 hertz
Is there a lost art to writing code without a text editor, or even a (passable) computer? It sounds romantic, I’ve done it before, I tried it again, and…it was not that great. 🤷🏻♂️
Tooling has improved for ambitious software developers
Tools for working on software in the large1 have improved a lot over since I last considered them ten years ago.
Err the Blog, revisited
Before there was GitHub, there was Err the Blog. Chris Wanstrath and PJ Hyett wrote one of the essential Rails blogs of early Rails era. Therein, many of the idioms and ideas we use to build Rails apps today were documented or born.
I’d figured this site was offline, as are most things from the mid-2000s. ‘Lo and behold, it’s still online in its pink-and-black glory. Lots of nostalgia on my part here.
Make code better by writing about it
Writing improves thoughts and ideas. Doubly so for thoughts and ideas about code.
Writing, about software or otherwise, is a process wherein:
- thoughts and ideas are clarified
- ideas are transferred to colleagues
- culture (of a sort) is created by highlighting what’s essential and omitting what’s transient
Documenting code, as a form of writing, is a process wherein:
- the concepts and mechanics in the code are clarified
- what’s in our head today is made available to our teams (and ourselves) in the future
- culture happens by highlighting what’s intended and what’s “off the beaten path” when working with this codebase
I suspect that open source is (often) of higher quality than bespoke, proprietary software because it has to go through the crucible of documentation. Essentially, there’s a whole other design activity you have to go through when publishing a library or framework that internal/bespoke software does not.
I can’t objectively verify this. Subjectively, when I have made the time to write words about a bit of code I wrote, it has resulted in improving the design of the code along the way. Or, I better understand how I might design the code in the future.
Writing is a great tool for designing code. Use it more often!
Turn the pages. Read the code. Hear the words.
“Turn every page. Never assume anything. Turn every goddamned page.” — Robert Caro, Working
So goes the wisdom super-biographer Robert Caro received from a mentor when he was an investigative reporter in New York. Caro went on to apply this energy and depth to write a sprawling biography on real estate developer Robert Moses and four volumes on the life of LBJ.
I like the energy, determination, and purpose of Caro’s advice. In his writing, Caro takes a maximalist1 perspective2. He looks to understand the system. Caro read every original document in every archive he could find (“turning the pages”) to ensure he fully grasped the context of historical events and didn't miss any details that might change the interpretation of events. Caro tries to load the whole state of his subject into his head and notes. Only then does he start writing his expansive biographies.
1. Read the code
Building software benefits from the same energy and determination displayed by Caro. As I’m working on a project, I flip between code I’m writing, code I’m using, and adjacent systems. Once I’ve read enough to have the problem and system in my head, I can move through the system and answer questions about it with that everything is at my fingertips feeling3. Fantastic.
Recommended: read third-party libraries, frameworks, standard/core/prelude libraries. Read demo code. Find inspiration, learn something new, and build the muscle for reading code with confidence.
2. Hear the words
When I’m really listening, avoiding the urge to think through what I’ll say next, I’m doing my best work as a coach or mentor. When I really hear and understand what a colleague is trying to accomplish or solve, it’s a bigger win for everyone.
Subsequently, I can switch to brainstorm or solution mode. Not before.
Recommended: literally listen to what they’re saying. Especially for the leaders and managers out there. Get the context needed to understand what they’re thinking. Ask clarifying questions until you’re sure they understand what they’re thinking. Don’t start responding until you’re sure you understand the context and the kind of response4 expected of you.
3. Build a model
Reading (words and code) and listening are great ways to build a mental model of how an organization, system, team, or project works. That said, a model is mostly predictions, not rules or hard-won truths.
To verify your model, you have to get hands-on at some point. A model is likely invalid unless it’s been applied hands-on to the system in question. Make a change, propose an updated process. See what happens, what breaks, who pushes back. Building (with code, with words) upon the model will evolve your understanding and predictions in ways that further reading or listening will not.
Recommended: turn reading words, reading code, and listening into a model of how your code-base, team, or organization work together. Apply that model to a problem you’re facing and use the results to improve your predictions on what actions will produce welcome outcomes. Rinse and repeat.
4. Go forth and deeply understand a system
With due credit to Robert Caro, I suggest doing more than “turning the pages”:
“Read the code. Read every damn function or module you’re curious about.” — me, a few months ago
"Listen to what they're saying. Hear every damn word until they're done talking." — me, several weeks ago
Next time you think “I need more context here” or “that seems like magical code/thinking”, go deeper. Take 15 minutes to read the code, or listen 15 seconds longer to your conversation-mate.
Turn the pages. Read the code. Hear the words.
- Aside from his biography quote above, all of his books are doorstoppers. ↩
- Extensively aided, it should be noted, by further research and organization by his wife. ↩
- Aka Fingerspitzengefühl ↩
- e.g. commiserating, brainstorming, un-blocking, taking action, etc. ↩
Remote work skills today look like being online in my youth
Checking my emails frequently. Responding to a few group/direct-message chats at a time. Managing to write code, do math, or put together a slideshow/essay at the same time. Always in front of a computer.
That’s what productivity in my college years1 looked like. There was lots of multitasking and goofing around online. A smidge of collaboration via nascent networks2.
There is little coincidence that’s close to how I work today. Slack is a better IRC3, messaging apps work a lot like AIM4 and ICQ5 did back in the day. I try to focus more and multitask less, to the extent that circumstances and discipline allow.
What strikes me is, when my career started6, that’s not how we worked.
In the early 2000s, if I needed to talk to more-experienced developers or managers, I wrote an email or walked over to their office/cubicle7 to try and catch them for a quick chat. If I needed to talk to a more junior developer who was just out of college (like me), I sent them an instant message. I probably had Slashdot, IRC, or several blogs open in a minimized window somewhere.
Now, I’m the experienced developer/manager-type person, and the style of work matches a lot of my college habits. A lot of that is leadership determinism (i.e., I have the agency to set and model the structure of our work). Maybe some is down to measurable productivity improvements that, e.g., Slack bring. Most of it feels like it is down to the opportunity seized of remote work – you can’t work remotely without all the tools folks in my cohort started using as we were pivoting from students to professionals.
Today, “Extremely online” is a whole other thing that is unrelated to how I work professionally. But as a new generation becomes the largest in the workforce, probably that will change and things will look a little weird to me. So it goes!
- 1998-2003. Most of those spent on a dual-everything Linux PC. I bought my first laptop/Mac in December 2002. ↩
- Mostly, folks were Very Offline. Especially outside my generation, but even in my peer group. Now, we’re all Pretty Dang Online. ↩
- For all but the neck-beard-est measurable axes. ↩
- AOL Instant Messenger, the definitive software of my youth. ↩
- Which required knowing your user ID to get people to add you as a friend. Thusly, I can still tell you my ID to this day: 11772935. ↩
- Roughly 2000 is when I did my first productive programming for money. ↩
- Thinking back, cubicles were not great or cool, but they did beat desks in an open layout on most axes. Larger pair cubicles with someone you like to collaborate with were pretty good, all things considered. ↩
Top of Mind No. 3
Working in small increments towards medium-to-large projects or outcomes is tricky. I too frequently find myself down a much deeper rabbit hole than I’d intended. And I’ve spent a lot of time thinking about it and practicing at it! Recommended reading: Simon Willison on productivity.
Read-only and write-only modes of accessing social media – there’s something good here. E.g., blogs and feed readers are distinct from most1 posting software. Currently, I’m reading Twitter once a day, as a digest, without the ability to scroll an infinite timeline. If I want to post, I open up an entirely different app that nudges me towards writing instead of dashing off hot-takes. Interestingly, Typefully and Mailbrew are what I’m using for this and are made by the same team. I wonder if that was intentional or a happy accident?
Billing/subscriptions/payment projects are absolutely crucial, “undifferentiated heavy lifting”, and difficult to pull off. I have a ton of unstructured ideas about this. The latest kernel of an idea: billing projects are very likely to involve weird interactions between business goals, customer psychology, and anecdata.
The nap hierarchy – naps are probably in my top 5 list of work-from-home benefits.
- Early versions of NetNewsWire and Userland Radio notwithstanding. ↩
Think your thoughts
We live in the most amazing time for ideas. They’re all over the place. It’s never been easier to share them, and indeed they are shared at a phenomenal pace1.
It’s so easy to find ideas that it’s a little difficult to squeeze our ideas into the noise. Plenty of folks will tell you how to “build an audience”, but I want to make it personal.
Build an audience with yourself!
Make room for your thoughts to exist in your head despite all the noise that exists in our modern world.
1. Clear mornings
I’m a morning person. I do my best work early in the day. Look at my calendar, you’ll see this. One giant, defensive block to focus in the morning and get stuff done. Please — do not schedule me in the morning2!
However, I’ve come to think there’s more to a good morning than a clear schedule. Having a clear mind, with stillness and lack of lingering stressors, helps a lot! If I wake up with something bouncing around in my head, seize it or solve it. Write it down to think it through or solve tension3 my brain has dwelled on overnight.
Going deeper into a clear mind reveals the absence of others. A truly spectacular morning of creativity correlates to (almost) exclusively thinking my thoughts. My ideas in my head4 — great! Someone else’s idea, via social media, television, books; promising, but likely not as good.
2. Attention machines
Among books, television, podcast, radio, etc., ideas via social media are particularly hard to avoid. I have to put a lot of discipline/energy into “don’t open socials, chats, emails, news, etc.” before 11:30am lest another idea trample over my idea.
Modern social media has evolved, in form and function, to bypass the smart part of our brains and go straight for the emotional and often irrational part. It’s the upsetting and frustrating ideas that stick with me when I use social media. Rarely do I open my laptop, read social media for a few minutes until a good idea comes up, and then close the laptop to go think about it.
The doom-scroll demands more scroll.
The upside is, we may also live in a moment where the abundance of ideas surfaced by attention machines comes into balance as alternatives to hyper-scaled social networks come into play. I’m hopeful that to a smaller extent, Robin Sloan’s words on de-leveraging from Twitter will start to ring true as Twitter, in particular, fades from prominence:
The speed with which Twitter recedes in your mind will shock you. Like a demon from a folktale, the kind that only gains power when you invite it into your home, the platform melts like mist when that invitation is rescinded.
3. No retreat
The previous is not to imply that attention machines aren’t useful! I don’t want to Waldenpond or go full digital luddite. When I squint at it with optimism, some forms of social media look like a networked/distributed system attempting to reach a consensus5.
There are less intense attention machines that aren’t built around hyper-tuned engagement loops. Basically anything where I have a list of things to watch/read/enjoy is an attention machine: a Netflix watch list, YouTube subscriptions, Substack subscriptions, and the humble/old RSS reader. These don’t demand that I stay in a loop, thinking other people’s thoughts and consuming the surrounding ads. Which is useful because I want to get other people’s thoughts, but only on my terms.
I find that my thoughts are more interesting if I prime them with idea from specific authors via various primary sources, social networks and otherwise. It’s thrilling to discover new scenes, folks self-organizing into web-rings and networks and chats to think about or share the commonality and challenge of their work or hobby. Having that kind of energy bouncing around in my head tends to improve my ideas rather than dilute them like hyper-scaled social networks might.
Bottom line: keep using the web to find fascinating people and scenes, participate in a few of them.
4. Seize your thoughts
I return to A Precious Hour from Rands in Repose, a lot:
Each day I blocked off a precious hour to build something.
Every day. One hour. No matter what.
Every day? Yup. Including weekends.
An hour? Yup, 60 full minutes. More if I can afford it.
Doing what? The definition of “building a thing” is loose. All I know is that I get rid of my to-do list, I tuck the iPhone safely away, and if there is a door, I close it. Whether it’s an hour of Choose yourownadventure Wikipedia research, an intense writing session, or endlessly tinkering with the typography on the site, it’s an hour well spent.
Make the most of the mornings (afternoons, evenings, whenever it is for you). Work the thoughts I find compelling, not merely upsetting or prevalent. Share it with interesting people. That’s how an exciting life of thinking my own ideas happens6.
- For better or worse! 😬🤷 ↩
- This is as much a message to myself as anyone else. Too many times I’ve scheduled an appointment in the morning thinking “surely it will be fine this time” and surely enough current-me regrets the decisions of past-me. ↩
- Usually: think it through by writing it down. ↩
- What a concept! ↩
- See also: Graph Minds. ↩
- I think! ↩
Top of Mind No. 2
How I work: what might “pairing” with a language model-based assistant (e.g. GPT-3) look like?
How I build: the tension between the web platform being more capable than ever versus the difficulty of standing up many kinds of “basic” applications. e.g. animation is better/more sophisticated than ever, but skipping ahead with building web/database applications requires expertise and a few hours to get something up and running.
How I collaborate: encouraging teams to work in issue threads, thereby improving the quality of thinking (via writing) and building ambient, asynchronous awareness amongst teammates.
One thing at a time, incrementally
Only Solve One New Problem At A Time, Ben Nadel:
The example he gives in the episode is "learning Golang". Understanding how to use Golang was a new problem for the company. As such, in order to start integrating Golang into their work, they applied it in the context of an already-solved problem: sending emails. This way, Golang was the "one thing" they were solving—the email-sending logic already existed in Ruby; and, they just had to port it over to a new application server.
Good advice for any developer at any experience level1!
The ability to focus on one concern at a time is possibly the mark of a senior developer. It takes experience to ignore other factors as noise. It takes time to learn how to avoid tripping on distractions/side-quests. Distinguishing useful, new information from distraction and noise is the mark of a focused senior developer.
The trick for juniors, is they’re always learning more than one thing at a time, often on accident. They want to build a feature, but it requires a new library, and it requires learning the library. They went to start up my development server, but then something weird happens with Unix. It's the essential challenge of being a junior – they’re just getting started, so they’re always learning a couple of things at a time2.
If I could be so bold as to add a corollary to the rule of "one new problem at a time", I'd suggest that if it can't be done incrementally, don't do it. Over the last 6-years, feature flags have revolutionized the way that I work. And, a majority-stake in that change is the fact that everything I do is now built and integrated incrementally. Until you've worked this way, it's hard to even articulate why this is so powerful. But, I literally can't imagine building anything of any significance without an incremental path forward.
Working incrementally: absolutely, more people should do this. Even seniors. Especially myself!
Now, the tables can turn. I’ve observed juniors who are more adept at working incrementally than seniors. Because they’re tripping over other tasks all the time, the junior has to work in smaller increments to make progress.
Perversely, a senior who can see the whole feature/change in their head is sometimes tempted to push the whole thing through in one (large) change. Developers who have learned3 to avoid pitfalls and gotchas sometimes have to relearn how to work incrementally.
I speak from experience! Working incrementally is something I consciously have to work towards. Conjuring a masterpiece into existence in a fury of git pushes and one pristine pull request feels good. On net, a big bang of development is a detriment to my team. An early pull request, small tactical commits, and a write-up to describe why and how I got there are more useful to align the team and spread ideas.
Previously: one priority is like wind in the sails.
- I’m looking a this sentence again, double checking it, and yes this is a global pronouncement about programming and developers and yes I think it carries its weight↩
- Or even worse, accidentally learning things that aren’t relevant to what they’re trying to tackle. Sometime, ask me how excited I was about Tcl/Tk in 1998, arguably several years past the apex of that language/toolkit. ↩
- Often through the luck/privilege of having lots of time to practice/tinker at programming outside the job! ↩
Get professional value out of the next Twitter-like thing
The Bird hit another inflection point on Friday. Now, many people, myself included, are looking at alternatives or actively decamping1. It was quite a thing to experience.
Several days before, I read a post about the value one can potentially get out of Twitter. On one hand, it may not age well2. Network-effects will cause Twitter to lose “value” faster than it loses daily/weekly/monthly active users. On the other hand, thinking about how I might get tremendous value out of the next network is a useful thought experiment.
Herein, allow me to riff on how to get a surprising amount of professional value out of publishing to and participating in Twitter-like3 social networks.
The value proposition is two-fold:
- the ability to publish into other folks' attention streams (i.e., reputation building)
- a high-quality stream of information to adjust my own world view/model
On the publishing/write side: note that folks like Patrick, Simon, and Laura are Very Good at Twitter. They’ve been writing there for years, building a reputation. In particular, they form thoughts such that they travel and evolve well on Twitter in particular.
With a lot of practice, I could reach this level of operation. Building the reputation, of course, is about showing up consistently for months and years. A few months of rebuilding my Twitter routine and ‘practice’ and I’m out networking with the best.
In other words, use Twitter as a big professional networking tool4. Instead, the networking happens at the idea level. Contribute and participate in developing ideas and the network comes to you.
On the read side: I'm guessing anyone who enjoyed Twitter in 2022 and gets useful signal out of it is equipped with:
- a well-curated list of mute-words5
- bespoke user lists which focus the valuable discussion and reduce the din of a global social/information network
Throughout its history, Twitter was often adversarial. There’s a “main character” of the day. Many folks come solely to build them up or tear them down. Disagreeing parties come to dunk on each other. Occasionally, they directly engage, but social bubbles/fortifications are the norm.
Anyone who gets professional value out of Twitter ignores that aspect. 🤷🏻♂️ In particular, they are using Twitter itself (or well-considered 3rd party applications) to automate filtering out the noise6.
I’ve dabbled in setting up mute-words and curated, high-signal lists. It worked pretty well at various points in Twitter’s history, particularly in combination. Perversely, now that we’re possibly in the waning days of Twitter’s influence, I’ve got a pretty good setup for finding interesting, new-to-me ideas. Sometimes those ideas put my work, or even the world, in a better perspective. That’s valuable!
Bottom line: you get out of Twitter-like networks what you put into it. The better I write, work the network, choose your sources, and manage the flood of information, the more likely interesting/valuable things will come my way.
- I feel like this happened at least twice before, probably circa 2015 and 2018? ↩
- This started off as a thread that ended with this caveat: “Assuming that Twitter doesn't drastically regress under New Management.” Reader, it did indeed regress. ↩
- Tumblr, Mastodon, Micro.blog, Cohost, Fediverse, etc. ↩
- Not in the way LinkedIn aims to do that around the resume. ↩
- I started with this list, which is unfortunately paywalled now ↩
- Mastodon in particular has community conventions around content warnings and requiring consent to see upsetting images or even posts about ongoing dramas. By social convention rather than software or regulation, this makes it a much better place for human brains to hang out. ↩
Updating Eisenhower on planning
Previously: a long time ago, Dwight Eisenhower probably said something to the effect of: “Plans are useless, but planning is essential”.
Today, software development (and knowledge work writ large) are largely about speed in the service of more. Iterate faster, ask more questions, get more feedback, deliver more often. Success is less likely about having a good or well-formed idea from the outset, and more about how the idea evolves in the hands of people/customers.1
Let’s update Eisenhower’s insight on planning to harmonize with speed and quantity of iteration:
Static plans are useless, but dynamic plans, developed and iterated as information arrives, are the essence of leadership.
You have to plan. Stopping to think a multi-week project through isn't Waterfall or a slow, bureaucratic process. It's how you get your head into a project.
Lacking a plan isn’t an option2. If you choose not to have a plan, you’ll likely end up part of someone else’s plan. Their plan may not have the same outcomes or parameters in mind as you do. Better to have a plan.
Planning with your team is how you get everyone aligned and pulling in the same direction. The worst cases for a plan, that it’s tragically incomplete or wholly invalid, have a silver lining wherein the team that plans together pulls together. In the best case, you’ve front-loaded a bunch of coordination and collaboration, allowing teammates can work autonomously and efficiently.
The initial plan you or your team come up with is very much a rough draft. Surely risks will make themselves known and areas of unknown complexity/scope will present themselves. Don't worry about rigorously adhering to the plan once you're a few weeks into the project. Iterate and add to the plan until you’ve done all the useful work, and it's time to start planning the next project.
- There is something to say about slowing down, seeking quality at every turn, and delivering a great, monolithic thing. Usually that involves some combination of internal iteration, auteur mindset, a strong creative scene, or harnessing lightning in a bottle. Everyone wants to fall in this category but counting on that is an unhedged risk. ↩
- With apologies to Rush: “If you choose not to decide, you still have made a choice”. ↩
Programming excellence: a small matter of practice
The key is deliberative practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes. Then repeat. And repeat again. There appear to be no real shortcuts: even Mozart, who was a musical prodigy at age 4, took 13 more years before he began to produce world-class music.
Peter Norvig, Teach Yourself Programming in Ten Years
Norvig's recipe, paraphrased:
- get interested and program because it's fun and continues to be fun
- learn by doing
- talk with other programmers, read other programs ("This is more important than any book or training course")
- work with other programmers and after other programmers
- learn several languages with diverse capabilities and philosophies
- learn the "computer" in "computer science"
And here I am, twenty-five years in, wishing I'd practiced more 🤷🏻♂️😆
Write more, coder inspiration, queryable coding environments
Simon Willison on writing about one's work:
A tip for writing more: expand your definition of completing a project (any project, no matter how small) to include writing a blog post (or README or similar) that explains that project
Without this you're skipping a relatively small step that unlocks a huge chunk of the value in the work that you have just completed!
This advice goes for internal company work too
I set up an internal blog at a previous employer using Confluence (because it was already available and has a good-enough blogging feature), but even something as simple as a dedicated Slack channel can work well for this purpose
And, writing more by lowering standards 😮
And as always: one big secret to writing more is to lower your standards
Published but "could have been better" is massively more valuable than something that eternally sits in your drafts
One of the biggest productivity improvements I ever made to my blogging was when I gave up on my desire to finish everything with a sparkling conclusion that ties together the whole post
Now I embrace abruptly ending when I've run out of things to say instead
Spoiler: I’m following this advice right now! 📈
---
Thorsten Ball collects greatest hits by Steve Yegge (who coincidentally just joined Sourcegraph):
- Rich Programmer Food, on compilers
- Notes from the Mystery Machine Bus, on the political philosophy of software engineering
- The Google Platforms Rant
- Execution in the Kingdom of Nouns, on the ills of typical mid-2000s Java/OO design trends
- Bonus: I had no idea Steve Yegge has an active YouTube channel.
And, on books/screencasts/blogs that have influenced him most as a programmer. A few that have influenced me too:
- Destroy All Software
- PeepCode Play by Play
- Pragmatic Progammer
- Practical Object-Oriented Design in Ruby
- Agile Web Dev with Rails
- Rands in Repose
- Code Complete
- 37signals' books
---
Codebase as Database: Turning the IDE Inside Out with Datalog:
I’ve been wondering: what if this codebase model was as queryable as a database is? What new questions would we ask of our codebases, and what new ways would we find to visualize them? Furthermore, what if the language semantics themselves — types, completions, errors, etc — were specified as queries, which were also introspectable?
I believe that the design of languages and programming environments should not just be the province of a small priesthood of elite developers. Everyone should be able to look under the hood of their IDE, and be free to push its boundaries: embed it in a different context, create a domain-specific language with rich editor support, fork an existing language to play with its semantics, etc.
The opacity of the IDE’s inner model — and the rules by which that inner model is updated — are barriers to this being a reality. For IDEs to be introspectable and hackable, we must first expose this model and these rules: we must turn the IDE inside out.
Sign me up for queryable, malleable IDEs. I like RubyMine and JetBrains' development products a lot. But, I often pine for the speed and low-ceremony extensibility of Sublime Text (or TextMate, back in the day). So let's through "as easily queried as a database" on the pile while we're at it. 😆
See also: Sourcegraph, language servers. (Someone in the back is yelling Lisp, the "Freebird!" of software development.) Furthermore, I wish Jetbrains' MPS was less Java-centric and more tractable.
Onboarding when you don't have access to the team
Mitchell Hashimoto, Contributing to Complex Projects:
The first step to understanding the internals of any project is to become a user of the project. You do not have to become an expert user, but my personal graduation criteria for this step is to try to build something real using the project, even if it is small or simple.
Analog: here's a functional area. Set it up for yourself or on your localhost. Now, make a small, well-contained change.
Learn how to build the project and get a working binary (or equivalent). Don’t bother with understanding the build system, the dependencies, etc. Just cargo cult guides, websites, whatever you need to reliably and repeatedly go from source code to runnable binary on your system.
Analog: get to the point you can run the app, run (focused) tests, and see changes in the app. Then start trying to make functional changes.
To learn the internals, I like to use an approach I call “trace down, learn up.”
Analog: for your first several changes, read from the top of the call stack down as far as you can. Don't try to make changes, but do try to note all the landmarks (files) you visit and how they relate to each other. Note “side quests” to investigate later as you go.
Don’t be afraid of complexity. I think too many engineers look at stereotypically complex projects such as programming languages, browsers, databases, etc. as magic or as destined for higher-beings. I like to remember that all projects were started by other humans. If they could do it, I can do it too. And so can you.
You, too, can gain enough understanding of an eight-year-old system to work on it as though you were around when some of it was written. In fact, your effort will compound: the longer you're around, the more you will find curious code that, it turns out, you added in the first place. 😆
Perspective, you want it
Perspective is the lens we view our world, work, relationships, etc. All the luck, resources, or knowledge in the world are wasted without good perspective. If we’re talking about life like it’s a role playing game character sheet, you want to have a good perspective stat/multiplier.
Some clever tricks:
- keep the mind open and flexible to other perspectives; seek them out
- practice at holding many perspectives simultaneously
- know the limitations and strengths of a perspective as you navigate the world
- know when your default perspective makes a scenario more difficult and how to fall back to a perspective you still believe in
- get out of routines periodically and see if it changes how you see things
- more so, get out of your bubble; see people of a different background live their lives, reflect on what factors brought them there and how factors are different/similar for your life
- even more so, travel outside your city/state/country; axiomatically the people most different from you live in a place far away
It’s often tough to gain perspective. Most of the defaults in life steer us away from insight. School, cliques, work, even typical travel nudge us toward seeing familiar things with similar people who live similar lives. I’m by no means an expert at breaking out of these ruts. I’m pretty enamored with my routines. Unfortunately, I don’t have a clever trick to offer here.
Julian Shapiro, What you should be working on:
What is admirable is periodically killing your momentum to ask, Should I still be doing this?
Michael Lopp, The Art of Leadership: Small Things, Done Well:
Let others change your mind. There are more of them than you. The size of your team’s network is collectively larger than yours, so it stands to reason they have more information. Listen to that information and let others change your perspective and your decisions. Augment your obvious and non-obvious weaknesses by building a diverse team. It’s choosing the path of least resistance to build a team full of humans who agree with you. Ideas don’t get better with agreement. Ideas gather their strength with healthy discord, and that means finding and hiring humans who represent the widest possible spread of perspective and experience. Delegate more than is comfortable. The complete delegation of work to someone else on the team is a vote of confidence in their ability, which is one essential way that trust forms within a team. Letting go of doing the work is tricky, but the manager’s job isn’t doing quality work, it’s building a healthy team that does quality work at scale.
Former president Obama perfectly explains why he was so committed to reading during his presidency in a recent New York Times interview (paywall): “At a time when events move so quickly and so much information is transmitted,” he said, reading gave him the ability to occasionally “slow down and get perspective” and “the ability to get in somebody else’s shoes.” These two things, he added, “have been invaluable to me. Whether they’ve made me a better president I can’t say. But what I can say is that they have allowed me to sort of maintain my balance during the course of eight years, because this is a place that comes at you hard and fast and doesn’t let up.”
Leadership keywords
My current theory of leading software teams and projects has four keywords:
- Trust: I assume everyone is working to get the job done. They assume I will help them get the job done. This starts off more like faith and grows into trust as teams coalesce.
- Autonomy: each person on the team is independently productive for a significant chunk of their day. When they make assumptions to stay unblocked, they are adept at collaborating asynchronously to verify them or correct course.
- Agency: each person solves the task they’re working on in a way they see fit, within the conventions shared by the team. If an interesting idea comes up outside of the those norms, anyone can pursue it such that they maintain the trust/faith of their colleagues.
- Support: each person knows that the team, particularly yours truly, is there to help each other. This most often manifests as pairing on troubleshooting, designing, coding, etc. Most importantly, sometimes it is sharing the load when one person is feeling overwhelmed.
Support is a recent addition. I had previously thought that autonomy and agency were the things enabled by trust. But I’m starting to think1 support is a crucial part of the equation too.
Without support, you’re just throwing people into the pool and telling them they can stay a-float however they like. It omits the “get good enough to swim” part, which is pretty crucial!
This kind of support is most obvious when you’re bringing someone new onto a team. But you need it throughout an individual’s tenure on your team. The people with years of deep experience and history in their head need support of a different variety.
Teaser: I’m on the fence about adding 2-3 more words to my repertoire. There’s a lot of moving parts to leadership!
- Largely due to onboarding people to a team/system/organization with a long history. This doesn’t happen without a larger-than-normal support effort. Perhaps that effort is amortizable over time (i.e. writing docs), but it’s still a big lift. ↩