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.
I’m cool with story points, as long as I’m not asked to make them up or care about what others’ story points are. 🤠
"Inspection does not improve the quality, nor guarantee the quality. Inspection is too late. The quality, good or bad, is already in the product."
W. Edward Deming
And here are a few screenshots of an interview with Deming:
and
A toxic trait of some devs I can’t stand is when they write their opinions in confluence/notion/etc and then point to it as “the standard” whenever someone says something that goes against it.
Best practice: write your own version, but prepend the title with “Updated:”
Reviewing all the tickets for an entire week and expecting everyone to be able to have enough context on everything is a ridiculous way to plan your week.
Instead: Work smaller. Have the courage to speak up and say “I can’t care about all those things right now. I need deliberate attention and focus on the thing right in front of me right now and everything else is a distraction. I’ll give the same amount of attention to all those other things when I’m working on them.”
That’s not to say you shouldn’t be aware of the bigger picture and know what else is going on.
If it’s not in main, it doesn’t exist.
Watch Charity Majors awesome talk: “The Sociotechnical Path to High-Performing Teams”
You won’t be disappointed!
Bad managers take silence as acceptance.
Often, they should be hearing it as hopelessness.
It’s fine to have strong opinions, but don’t dismiss others if they have a differing opinion. Their reasons are often just as strong as yours. Listen to them. You might learn a thing a two.
A few interview questions to consider.
What’s the whole process for getting one line of code changed into production?
- I once had to remove a link from an admin dashboard. The process to do that was 52 steps.
Humility is an enabling principle that precedes learning and improvement. A manager must be willing to seek input, listen carefully, and continuously learn. They do not know it all and readily admits that. When you have done this? How often?
How do speed and quality relate?
- After they answer: Does frequency of feedback affect this, and if so, how?
What does the phrase “test in production” mean to you?
Who owns the board? Is it viewed as Products board?
Do you put ticket numbers on each commit?
Do you incentivize improvements? And how soon? What type of improvements do you value?
How do you recognize when you’re stuck in the “we’ve always done it this way” trap?
Are developers treated more like a line cook or a doctor?
In order to get better, you have to be intentional. If you’re not intentional, you’ll be average. What are you doing to be intentional?
I found myself fixing bugs constantly in the past few jobs I’ve been in. They didn’t have good practices, always rushing around, which led to bugs, and it was a constant firefight. What’s the situation like here?
How often are you changing our process to try to make yourself more effective?
- (there should be many recent examples).
What question did you wish you would have asked before you started working here?
If you’re the manager of a 7 person dev team, how many separate concurrent initiatives do you have? How did you reach that number?
If your team uses PR’s, how do you handle large refactorings? Do you have to create a story/ticket just for the refactoring? If it’s a large refactoring and other work is going on, do you plan on having a messy merge conflict when that time comes? How do you encourage small changes like typos, small refactorings, etc? Do you roll them into bigger PR’s and deal with the merge conflicts that others have later?
(If they bring up story points) How many dollars does a story point save or make?