- Can you describe the team’s biggest technical challenges right now
- How does the company encourage innovation? (Shows you value creativity.)
- Tell me about your last major migration. How long did it take and how long did you say it was going to take before you started?
- Let’s say I’m the person you hire. 6 months have gone by, what’s different?
- How much annual turnover do you have?
- How are people who experiment treated?
if you need to inject a message into a wall of text printed to the screen, like when starting jekyll or astro or rails server, you can read lines and print it at the appropriate time.
#!/bin/bash
pnpm run dev | while read line
do
echo "$line"
if [[ "$line" == *"Local"* ]]; then
echo "✅ Your site is live! 🎉"
fi
done
When we never talk about the product, I can’t gain domain expertise. Looking only at code doesn’t tell me where we want to go.
I’m watching this video on how you shouldn’t keep a backlog and they made an interesting point.
No other industry sees a backlog as a good thing.
They all want to reduce it.
Except software dev.
Why is it different? Or is it not?
I came across an old note that detailed how two members of a team I was once on was showing the rest of the team how to estimate.
Me, being a fan of #no-estimates, or continuous forecasting if we are asked to predict the future, was really going to enjoy this.
On May 11, they were able to T-shirt their way into confidently saying that the project would ship on August 20.
Of course they didn’t hit that. Last I heard it was at least a year late.
This still cracks me up.
Confidently declaring a date is not confidence.
It’s false-confidence. Don’t believe it. Don’t ask for this. All it does is lead to distrust.
Bad news doesn’t travel up.
I started my career on an eXtreme Programming team where we constantly evolved our processes and openly discussed what wasn’t working. Being my first job out of college, I thought this was standard practice. After working at several companies since then, I’ve learned that such transparency and commitment to process improvement is actually quite rare.
The book, “The Fearless Organization” dives into this a bit.
People don’t speak up because of:
- Don't criticize something the boss may have helped create.
- Don't speak up unless you have solid data.
- Don't speak up if the boss's boss is present.
- Don't speak up in a group with anything negative about the work to prevent a boss from losing face.
Speaking up brings career consequences.
It sure does.
Somewhere online (probably reddit) like 15 years ago I came across the phrase
“tutant meenage neetle teetles”
and I’ve kept it in my notebook ever since because it cracks me up.
Really good walk through of using ferrum to scrape and crawl the web: https://railsnotes.xyz/blog/ferrum-stealth-browsing
I often get told that I’m asking questions that engineers shouldn’t worry about. The cost of this or that, how this affects users, where do we want the actual product to end up as opposed to where we want this particular change to end up.
“Stay in my lane”, I’m told.
I ask questions outside of my lane because I’m tired of being laid off because they company is in financial troubles and yet I’m being asked to build a poll question module for the app that will not help our financial situation at all.
I’m asking the questions that should have been asked by now.
Being “Overly-Confident” just to show confidence is not a good thing.
You wanting me to be “overly- confident” to ease your need for a false sense of certainty is a you problem, not a me problem.
I feel like it’s the same people pushing for “overly-confident” ways are fans of radical candor. Their way is the only way. There’s no room for people who think different and if you do, you get labeled as not having confidence.
I like to be deliberate and think through the information, wrestle with it and really process it. I’m the opposite of what is wanted by the people who have the overly-confident disease.
I want us to be on the same page.
I’m not going to lie to make you feel better.
I just came across a service called Admonymous.
It’s an anonymous way to send feedback to someone. I’m curious to see what people think about me.
Life pro-tip: never take visits with parents, siblings, and other loved ones for granted.
When you start making up excuses to not visit, go anyways and ask about their past and how it shaped who they are now.
God what I’d give to be able to do that.
Man, I feel sorry for workplaces that require developers jump through the git hoops such as constant squash, fixup, drop, edit, cherry picking, branching, and merging, etc.
There are safer, saner ways to work with way less git-wrangling.
Congrats on knowing so much Git, I guess.
Good leaders clean up chaos.
They identify painful process that have become the status quo and simplify them.
They listen when someone on their team speaks up and they don’t become defensive.
They understand that the teammate is bringing it up for a reason. It may not affect everyone, but it affects them, at the very least.
Mental health is important.
The only ones wanting to separate the “thinking” from the “doing” are the thinkers who don’t know how to do the doing and the doers who don’t want to do the thinking.
Do you have a blameless culture? If so please describe a time and situation that demonstrates this, and your involvement.
People spend too much time thinking about how to give feedback, and not thinking about how to better ask for or react to feedback.
Here are some interesting things I’ve found this week.
Books and Articles
- I recently picked up Gene Kim and Steven Spears new book Wiring the Winning Organization. This is a great book I wish more leaders and managers would read and take to heart. This article gives a nice summary of what the book talks about. In my bubble, so many developers are focused on the language they’re using, some advance to the tools and how the platforms are wired together, but I have seen time and time again how things aren’t working at the social level. Teams can get more done with less stress, less rework, and less effort if they work in smarter ways. This article (and book) will give you the vocabulary to use to start thinking how to improve your organization.
- Everyone needs to hear more feedback. It’s how we learn, improve, and grow. Start by using these 3 questions to help the person giving you feedback, but really, these questions are training wheels. If you want to learn the nuances of feedback and how people react to it, pick up Thanks for the Feedback by Douglas Stone and Sheila Heen. This is one of those books that if I could make everyone read, I would. It’s my most recommended book by far (in the context of work).
Videos
PostgreSQL
Random
Branches are a bandaid for working in too large and risky ways.
When you work on an isolated branch, you’re causing others to not know how you’re changing the code base. And they don’t get to see it or work with it until you’re done. If you refactor anything and others are depending on the current version of that code in their branch, you are directly causing them pain if you merge before they do.
I know working with branches and Git Worktrees feel very productive and efficient, but there are hidden costs. It’s a trap when viewed throught the lens of the team. It makes you think about only your work and not think about the whole.
Git Worktrees are bandaid on top of branches. When you work in too large of chunks, you will be interrupted and need to work on something else mid-work, so you need yet another tool because your existing tools aren’t sufficient.
Continuous Integration, and the discipline required to work in small, safe ways, removes the need for all this.
It gets your code changes into main faster so others can build off of it. If there’s a conflict, it’s noticed sooner, and it signals who you need to talk to before proceeding. It prevents the rework and frustration that comes from late merges.
Turn photos of yourself into a Lego Minifigure.
I came across the Brick Yourself site and I love it. It uses some sick AI to analyze a picture you upload and turn it into a Lego figure. Here are a few of the images it produced from my pictures.
3 feedback questions you can ask to help the person you need feedback from.
Interesting links from week 3 of 2024.
Here are some interesting things I’ve found this week. I’m just getting started with this, so it may be a slow ramp up.
Elixir
TIL
Running mix ecto.dump creates a structure.sql file in ./priv/repo.
This is easy to forget to keep updated, so one easy way is to add this in the aliases() function in mix.exs:
"db.migrate": ["ecto.migrate", "ecto.dump"]
"db.rollback": ["ecto.rollback", "ecto.dump"]
I keep forgetting how to change the remote for a git repo.
1) View existing remotes
git remote -v
2) Change the ‘origin’ remote’s URL
git remote set-url origin https://github.com/user/repo2.github
3) Verify new remote URL
git remote -v
How to get a random number in Elixir.
iex(1)> :rand.uniform(6)
iex(2)> Enum.random(1..6)
Sometimes you need a unique integer, and of course Elixir has you covered. This is very useful for Factories if you want to implement something like sequences to avoid errors due to database unique constraints.
iex(1)> System.unique_integer(~w[monotonic positive]a)
1
iex(2)> System.unique_integer(~w[monotonic positive]a)
2
iex(3)> System.unique_integer(~w[monotonic positive]a)
3
A few interview questions to consider.
Has a developer ever been working on something really important and was asked for an estimate and it ended up taking 6 months longer because they learned something along the way that hadn’t occurred to them at the time of the estimate?
Tell me about someone who was in my position who did really well. What did they do?
- Look for red flags, long hours, firefighting.
Tell me about someone who went “above and beyond”. What did they do?
- Look for red flags, long hours, firefighting.
Rather than worrying about your five year plan, what’s your plan to make a difference today?
More email newsletters should use RSS.
Oh no, you won't be able to collect emails to grow your audience for your content!
What are you ever going to do?
I will always prefer one of these ways of working over the other.
I have an extremely hard time to understand how the other is reasoned about or chosen.
1
2
If you like to work in long lived branches:
Why do you think that your work needs to be able to work in isolation from everyone else’s work?
At the end of the day, it’s one product. Your code needs to work with everyones code.
While you are probably not concerned if you find yourself in a bad merge conflict, you are just as likely to inflict a bad merge conflict on others.
Why are you okay with setting your teammates up like this?
There are ways you can work that doesn’t do this to your teammates.
Would you be willing to learn another way?
Deploy “commits”, not “complete features”. It will make managing “features” much easier.
❌ Don’t: “Here’s 40 commits, encompassing an entire feature; Deploy to prod and release to users immediately!; LETS GO!!!!!”
✅ Do: Safely nudge production just a little bit in this small way over and over again.
Deploying features maximizes the blast radius of the change.
Working in many small steps reduces it. This is the safer way to work.
I used to work like the following image until I discovered that team flow is more important than everyone being 100% busy. Finishing WIP is more efficient than devs constantly starting new work (and therefore causing more wait states). Working on multiple things “at the same time” is not efficient in any way.
Classic example of resource efficiency over flow efficiency.
Contrary to popular belief, shorter cycle times get more work done.
Things I Use
Mail Server Fastmail.com for important stuff, Gmail.com for everything else.
Notes Obsidian
To-Do Things
Calendar Fantastical
Cloud File Storage Dropbox for files I manage and iCloud for my computer configurations, dotfiles, etc
Browser Safari
Chat Discord and Keybase
Podcasts Overcast
Password Management 1Password
Launcher I have a customized Keyboard Maestro shortcut that I use to be able to open any of my common apps with a simple keyboard combination. This makes it extremely easy and fast to open any of my main tools without thinking. Spotlight is used for everything else.
Code Editor Neovim
Source Control (Hosting) GitHub
Git Fork for visualizations of all the branches, but mostly just Terminal
Terminal iTerm2
Macros, Automation, and Clipboard Keyboard Maestro
And yet, most tech interviews only test (poorly) for the left hand side.
The problem with trying to automate all the things, and building automations on top of automations, is that you’re never taking anything away. You’re just building on top of layers of cruft. The value of removing complexity BEFORE automating is seriously undervalued.
You can avoid having complicated git setups, rules, when to merge, when to rebase, etc, if you work to get your small commits that don’t break the build into main sooner. Instead of rebasing/merging 25 commits, get your code into main after 1-3 commits. The pain goes away.
Think you can’t work in such small steps?
I think you can. I believe in you if you try.
Adopting TBD, CI, embracing fast feedback cycles, etc isn’t about “going faster”.
It’s about increasing quality, detecting bugs and bad merges sooner, and affording the business the opportunity to pivot easier and sooner. It simplifies the process, increases productivity, and even increases team morale. It’s about lower risk, lower costs, and increasing value.
To think it’s just about speed is to miss the point entirely.
You’ll be better off reading books by the likes of Beck, Fowler, Farley, and Forsgren than by following tech YouTubers with opinion based hot-takes.
I think developers are the only group of people who want to practice solo, perform solo, and yet considers themselves on a team — while at the same time— never wanting to practice, perform, or improve together because it’ll hurt their individual PR, ticket, lines-written count.
Jerry Weinberg
Going from a team with full autonomy to having a manager who tells individuals specifically what to work on was one of the most irritating and demotivating things to experience in the tech field.
I have worked in a meta-programmed-spaghetti-code mess.
It was all approved via PRs but everyone agreed it’s trash now.
The PR process failed.
No one wants to tell the author it’s crap because “it needs to get out” to meet the OKR and “it works”.
“LGTM ship it.”
52 Easy Manual Steps to Deploying
Once upon a time, I was tasked with removing a link on in our app.
It took almost all day to get this done. Ridiculous! I wrote it out to visualize it. I wanted to see the context switching necessary so I added which app or webpage you have to be in to complete that step.
It took 52 steps to delete a link and get it into production.
A link…
52 steps…
52 easy steps…
The 8th step was where the link was removed. This is the only step that involved editing code.
Every step after it was what it took to get it out the door, updating jira tickets, updating teams on slack, etc.
How much money does this place have??
Things dump
- Automate manual deployments with Git and binstubs from Thoughtbot
If 15 branches don’t fix your problem, you might need a 16th.