and it's this very interesting little post where he talks about at the end of your day; you want to close the book on it. I think this is especially pointed now that many of us are working from home. For me, this is a new thing. And so, I've been very intentional with trying to put walks at the beginning and end of my day.
But in this particular blog post, he describes a routine that he does where he tidies things up and makes his list for the next day. And then he has a particular phrase that he says, which is "schedule shut down, complete."
- Improvement
And there's an adage that I think comes from biking, professional cycling, that it never gets any easier; you just go faster.
- Ask when members' next vacation is. https://www.bikeshed.fm/309
Have an inbox kanban category for incoming requests.
Have a point dev role for a sprint (or not a sprint, just a time period). Then someone can push a bellybutton. You can make a group in Slack and assign that person to it. Then anyone can just @point for a problem.
I know Charity Majors pushes really hard for 15 minutes from merge to deploy to production. And so if your CI suite takes 25 minutes, then already you're stuck.
More generally, this is something that you and I have talked about offline but the idea that you kind of always want to be hiring. We do have specific roles that we've identified that the budget has space for. But more generally, ideally, we're going to need to hire more people down the road, and that will happen at a particular point. But having those conversations, starting to talk to people, now planting the idea of like, hey, you're great, and I would love to work with you someday and just keeping those lines of communication open.
There was a thread about tracking down slow factories with ActiveSuppport::Notifications and FactoryBot but I can't find any details about it. The nugget in this was they found a 4 sec factory that was called many thousands of times. Without parallelism, it was 35 minutes just in this factory in a CI run. So making the factory a 2 second factory would save them 17 minutes. ed: I've done a similar thing with test-prof but it sounds like they might be listening to events and not watching the method call space (or however test-prof hooks in)
Ben Orenstein's podcast, The Art of Product and Shawn Wang: Preemptive Pluralization.
Ben basically framed the idea of like, I've never regretted pluralizing something earlier. A user has one account; they have multiple accounts. They just happen to have one at this time, et cetera.
"How do you feel about aggressive goals?" And I was like, "Well, it depends. How do you feel about aggressive failure?"
- Make every db field not nullable unless someone can explain why not.
- If you have null on a boolean column then you have a three state boolean:
true | false | null
Zero based indexing in the real world and not just for memory offsets. 19th century is off by one but 0th century would have fixed this. 1st floor (vs ground floor) has the same problem.
Learning with APPL
- Adventure (try something new)
- Passion (topic)
- Profit (from recent learnings)
- Low-risk (applicable today)
This is probably the best blurb I've ever heard. The sparking question was about generalist versus specialist.
I think, in a certain sense, there's no right answer. Like we said earlier, there are multiple paths to a career in tech, and you can go through both. I think something that I've seen be less effective, especially very early career folks, is trying to go too broad, jumping on every new language or framework every couple of weeks, every month, and just dipping your toe in it and then moving on to something else and never really learning deeply, or synthesizing, or building a mental model of things. And so you're kind of stuck in the shallow end forever, and it's hard to break through into that initial level of expertise.
So I think, especially very early career people, I tend to recommend pick one language or technology and focus on getting good at that and then branch out. And, of course, you're never doing everything in a vacuum because there are a bajillion dev skills you need to learn beyond a language or framework.
So I often categorize three areas to focus on that I like to recommend for people; one is pick a primary language or framework and get good at it. Two, learn some evergreen skills, these are things like version control, so Git, SQL, using the command line. And these are not things that you need to master on day one because you're going to use these your entire career. So learn a few things, move on, come back to them next month, learn a few more things, and just keep coming back there every now and then over the course of your entire career to deepen those skills, and that will serve you very well.
And then, finally, some random thing you're interested in. I find that I learn so much faster and so much more deeply on topics that I'm interested in or passionate about. And that interest can be very random sometimes, and it can also be fleeting. It can be, oh, I was interested in a thing for a little bit, and I dug into it, and then I moved on to something else.
If I have a career or learning plan, I like to leave that room for spontaneity to say there will be things that are maybe not strategically important as my next step, but I can learn them because I'm interested in them because they bring me joy. And then later on, maybe that will actually be the foundation of something important two years down the line where I can draw on that knowledge.
So TL;DR:
- Don't switch core technologies too often. Otherwise, you'll stay in the shallow end.
- Pick one language or stack and focus on getting good at that. Then branch out.
- Then learn some evergreen skills like Git, SQL or the shell (CLI).
- Don't master the evergreen skills, revisit them over your career.
- Give yourself freedom for inspiration. Study something that interests you.
I think for myself, with many heuristics, as a beginner coder, I had a bit of, like, a spiral journey, or maybe kind of going up a set of stairs. So, as a brand-new developer, I would make a lot of duplication bugs in my code, where, you know, I would have the same value in multiple places, and then I'd change it in one place, and I don't remember to change it in other places, and the code breaks.
And so, being introduced to the idea of DRY actually helped my code get quite a bit better. It was, like, a net positive on my experience because I was not getting burned by all these bugs quite so frequently. And so, for a while, just throwing more DRY into my code just made my life better. And then, eventually, you kind of hit that plateau where I don't run into the pain of these bugs anymore. But now I keep doing more DRY somewhat mindlessly. And I end up with this pile of abstractions that are actually really brittle or frustrating to work with. And now, I have to rethink some of the assumptions behind the heuristic.
And then, at that point, yep, maybe recontextualize a little bit, learn about when it's good, when are the trade-offs not worth it. Now I have a better understanding, and I kind of go on another growth bit where it makes a lot of my code better until maybe I hit another plateau. I've kind of maxed out the benefits. I start seeing some of the pain, and then, again, I have to go through this cycle again. And maybe the approach you were talking about earlier, where you do a side project and kind of push a heuristic to its breaking point, is a way to kind of speed run that process.