Your 50+ file change PR makes you stand out to your manager. Good job.
You just caused merge conflicts across the board.
Please, work in smaller steps.
Please, work in safer steps.
Yes, this means you will need to take many more steps.
But they’re smaller, so can be reviewed much faster.
Better yet, pair so it gets reviewed while it’s written and avoid the costly waste of time waiting for others to review such a small change.
By putting 50+ file changes into 1 giant PR (usually with 1 commit) you are shifting your lack of discipline and care onto everyone else.
By making smaller safer steps, every step of the way should be deployable, tested, understandable, etc. And you’re helping others follow your line of thinking.
Most important of all, get those changes merged in.
Others need to see the changes in the code they’re working on before your 50+ file change causes merge conflicts, reduces peoples willingness to do large refactors, etc.
The system teaches you to be loyal and then punishes you for it.
“We’re all in this together”
They’re not the ones skipping lunch and dinner with their family to make a deadline - they’re the ones setting the deadline.
They say, layoffs are “right sizing”, but when you “right size” your boundaries it makes you “not a team player”.
I’m often told I need to “be more confident”.
My question in response is:
What does confidence look like when it’s balanced with risk assessment?
Over-confidence causes us to fail in costly, embarrassing, and dangerous ways.
Are you sure you want someone who is overly-confident?
Personally, I trust those who are “cautiously right” more than those who are overly-confidently and mostly wrong.
“Confidence” is not the same thing as “certain”, “assertiveness”, “competence”, or “correctness”.
If you’re demanding someone be more confident, be sure that is the right word you mean.
Trunk Based Development requires your developers to be disciplined, willing to work in-step with each other, and to know what they’re doing.
Why do branch-based approaches not demand these things? What happens if you don’t have these things?
When I read or hear “I pushed up a non-trivial PR”, I understand that as “I couldn’t be bothered to do this work in a safe way by making small changes that worked at every step, so now I’m offloading understanding all the changes of 50+ files onto YOU! Good luck!”.
I’d argue this is pure laziness and shows a lack of discipline in the craft.
Then again, I think a PR process is a lack of discipline as well, but that’s another story.
command to get just the changed files from git and run in rubocop:
git ls-files -m | xargs ls -1 2>/dev/null | grep '\.rb$' | xargs rubocopI do not subscribe to the stack ranking approaches to “performance management”.
Hell, I do not subscribe to thinking that “performance management” helps in any way.
I have seen too many “high performers” get others to flip the mental switch in others that they can do no wrong. They set others up (either intentionally or not) and make the people who aren’t well liked be the baddie. It’s all just like high school. This is stupid.
Remember the saying “a bad system will defeat a good employee every time”?
This is exactly what causes it.
Regarding branches and merge conflicts:
Doubling down on using branches means these problems will continue.
Personally, I don’t want to live with problems that are solvable and the only reason we can’t fix them is … what exactly? The resistance to collaborating? Learning how to work in a way you haven’t experienced yet?
If you have problems with merge conflicts, adding more tooling to allow your branches to go on longer without being merged isn’t going to help.
What am I missing? How am I the crazy one for saying this?
I’ve been a big fan of “think in systems, not goals” for a long time.
I’ve had several managers who think in goals and didn’t want to see the benefits of this.
“Goals, goals, goals!!”.
SMART Goals.
Checking stuff off ‘the list’.
That’s how they saw the world. Everything was a checkbox.
And these same people would say that building software for clients was about people.
What type of checklists of goals did they have on other people?
The problem of having poor judgment is that you are a poor judge if you have poor judgment.
- 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
doneWhen 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’ve been in this business long enough that everything is a red flag anymore. I’ve seen everything I thought good used in evil, manipulative, and harmful ways. I don’t even know what I’m looking for in a job anymore because this industry is so fucked up.
I wish I wasn’t this jaded but here we are.
I’m pretty discouraged, as you might be able to tell. I’ve been doing this for over 20 years. Jobs are disappearing. The things I value aren’t valued in the business anymore. It’s just shit software all over but it’s built some amazing resumes out there.
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.
My Professional Summary
My Professional Summary
I have over 20 years of experience and a unique balance of a technical background coupled with the ability to manage, de-risk, and make the impossible solution possible. I have participated in every stage of the software development lifecycle within small to medium sized businesses. My focus is to produce well crafted, working applications with an eye on the end users experience while staying on budget and hitting timelines.
While all that is true, we all say that. Let me describe the work culture that I thrive in.
⚠️ Before we begin, I know not all places can or should work the same way - I'm not saying that. I'm simply sharing the environments where I thrived the most. Nothing more.
I like working on smaller teams, teams that “punch above their weight”. Being able to achieve more with less means that we get to reach out to stakeholders, other teams, and even end users. I absolutely love working as closely as possible with designers and all the “non-coders” because when we break those silos down, real work gets done faster and with higher quality.
The best way I’ve ever worked was with a “small mighty team” consisting of 2 or 3 developers, a designer, and the person wanting the product/feature/change. I guess most would call this the Product Owner, but I literally mean the person writing the checks who wants this work done. (I know that can’t always be the case, but it was for the two instances I’ve worked this way.) It’s the most productive, efficient, and effective way I’ve ever worked.
I like to get together for a day or two, discuss the next objective, create a User Story Map, and then we can get to work. We can repeat this process in a month or two when we close in on finishing our objective. We’re not doing any deep technical inspection here. The main points of doing this is to:
- Establish a “north star” and get everyone on the same page.
- Break down what the user needs to accomplish into slices that can be delivered in small incremental steps.
- Try to assess if any particular piece is risky, has an integration, etc. Anything beyond “just another ticket” kinda work. Do these first. If you can’t, you can’t do the project by definition and you save money by figuring that out before doing anything else.
We didn’t estimate anything; we didn’t guess on anything. We didn’t have planning or grooming meetings to distract us by taking our attention off of the work we were actually doing right now. Why load everything in this sprint and next sprint into our heads when we’re not ready to talk about them yet? Doing that just kills our attention.
I suppose the way we’d slice out work is a form of guessing since we tried to have each card doable in about a day or two. Whenever things took longer than that, we knew we had to reexamine the work and ask: Do we need to slice this further? Do we need to pull someone else in? Do we need more questions answered?
We didn’t even use sprints because they didn’t give any value with the way we worked. Since we already mapped out what needed done, we knew what was design heavy, what the risky parts were, where the integrations were, where we needed more info from other teams, etc. At this point, the PO, designer, and devs would talk and put a few cards into “Up Next”. No hour long meeting, literally it’d take like 5 minutes during any random standup. The PO would say “I want to focus on X” and the designer and devs would either say “Cool” or “We need to do this other thing first because of Y”. We’d adjust. We’d learn. We’d adapt.
Everything was like this. We trusted the PO to know the direction and they trusted that we knew what we were doing. The “PO” (again, the one writing the checks ) didn’t treat us like a line cook who just did as told. They treated us like a chef, as experienced professionals who knew how to make software better than they did. Not sprinting, not talking about every card that we were going to work on in the next two weeks, not going over everything in detail until it was time enabled us to focus. This is vital to writing great software. This is something I’ve found severely lacking on most teams.
Day to day, we put everything on a quasi-kanban board. We worked in small steps, communicating with the PO every day at standup to show progress and ask/answer questions. This allowed us to make necessary adjustments to ensure we were on the right track. It also enabled us to have the harder conversations when it wasn’t possible and we could present options.
Some teams had regular retros, but mine did not. Whenever we felt the need to discuss something, we’d talk about it right then (or whenever the person was ready to talk). Why wait up to 2 weeks to talk about something? If someone wasn’t comfortable bringing it up, they’d talk to someone they trusted and they would. Either way, we’d get it resolved, learn/adapt, and move on better than before.
We had WIP limits on our work and we would actively obey them. The flow of work slows down when there are too many things going on. Errors are introduced. Don’t start on new work! Finish what is already started! Help others first! Remove friction and blockers! Improve things you know need improved! Act like a Team Member and not a siloed off Individual Contributor!
We also pair programmed and used TDD every day, all day long. When you don’t know how to use a tool, it slows you down. When you know how to use them, they speed you up. Tests and TDD sped us up.
Of course we did Continuous Integration. I don’t mean the “CI/CD build tool” like how most people use that term today, even though we did have a build tool in place. I mean actual, for real, continuously integrating our code. The thing you do, not a tool you buy. We’d push to the main branch. We paired on the work, we reviewed it while we designed, talked, wrote, refactored, and committed the code together. And if it was a bigger and riskier bit of code, it’d be behind a feature flag or abstracted away so that we could selectively turn it on and off. This allowed us to get real world feedback as soon as possible which would then inform us for the next round of commits we’d do. All within the same day, sometimes multiple times a day.
I have seen first hand what this work style produces.
It’s very productive and efficient.
Dare I say even moreso than the big “Agile Frameworks”.
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
The only real integration branch is master.
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 -v2) Change the ‘origin’ remote’s URL
git remote set-url origin https://github.com/user/repo2.github3) Verify new remote URL
git remote -vHow 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)
3A 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