Being busier is better, right? Wrong. Or at least almost never. The trick is knowing the which situation you’re in.
How you describe a situation has a lot of impact on how you approch it. Do you take away or give yourself agency?
Sometimes the fastest way forward is to say No to doing something. The trick is knowing when to say no.
Are you letting low priority work hold higher priority work hostage? If you are, are you doing it on purpose, or by mistake?
Test driven development, Extreme Programming, and many other approaches encourage us to start typing in code, either as a test or as functionality. That’s good advice, but you should never start coding blindly.
Code reviews are part of almost all development workflows. How you write them, read them, and respond to them says a lot about a team’s culture. It’s also a way to adjust a team’s culture. How you use them is up to you.
Optionality is much more than having options. It’s about making the future possible instead of boxing yourself in.
Don’t just review it, review it BEFORE you show it to anyone. It’s good for you, it’s good for them, and it’s good for your code.
Providing customer value is what we’re all here for. Unfortunately, it’s not the only thing we end up doing because of demands on our time.
Winnie the Pooh is just over 100 years old. You wouldn’t think he has much to say about software development, let alone extreme programming, but Pooh’s approach has a lot to teach us. And not just in development.
George Boole brought us Boolean logic. There’s tremendous benefit in using it. But sometimes, it can also blind you to a deeper truth.
We deploy code and release features. We usually assume those two things are the same, but are they really? And should they be?
Do you want to optimize for is getting things done or for doing things? That’s a pretty subtle difference, but it’s an important one.
We think we want a one size fits all solution because it will be easier and save time. But it never does.
If you can subtract two times and take the average of a bunch of times, why can’t you add times? And what does that have to do with estimation anyway?
It happens to everyone. What happens next is what’s important. That’s where the blames post-mortem comes in
The Big Lebowski is more than a comedy or whodoneit. It’s a commentary on life. And the inspiration for Dude’s Law.
Knowing how to do something doesn’t mean you know when or where you should do it. Or even if you should. That’s the difference between skill and experience.
People want estimates. Or they say they do. What they really want is predictability and value. How can you provide both when you just don’t know enough?
No amount of talking about doing something will get it done. To get it done, you have to do the thing, whatever it is.
Every year brings changes. The goal is to learn along the way. Here’s some learnings from 2023.
Sometimes you just get stuck making a decision. How can you help your team move forward?
Have an opinion. Defend it. Defend other’s options. Be willing to change your mind.
Never drive faster than you can see. The trick is to know how fast that is.
Similar to MMMSS, you can also break your tasks down further.
All languages are not equal. You should use the language you’re using.
You need more than the ability to do the work. You need to be seen doing the work.
No one reads those automated status emails. You’ve got to radiate the information
Where you are influences not just what you see, but how you see it.
Tell em 3 times applies to more than presentations. It works in design too.
What if we were to think of the role of engineering manager as equivalent to a dungeon master? How does that lens change how we see things?
The hurrieder I go, the behinder I get.
Don’t just tell people what to do. Help them understand why they want to do it and how it’s good for them (and everyone).
Can you design for change and re-use? Should you? Isn’t doing one thing and doing it well the goal?
It’s very easy to fall into the habit of seeing like a state. It’s also not very helpful.
Clickbait titles aside, how you use your signals is important. Not just for measuring code coverage.
Time is hard. When you find out about something is just as important as when it actually happened. So you need to track ALL of the details.
You need to know where to step before you can worry about how far you’ve come.
You can only keep so many things in your head at once. The trick is making sure they’re the right ones.
It’s important to distinguish the how from the what and the why.
There are an infinite number of integers. How many do you use in your thinking and planning?
How can 2 be between 1 and 0?
What can Jazz teach us about the art of software development.
Because why you test is as important as what you test.
Releasing with stablity is good. Waiting for release to get stability, not so much…
Eventually what was a best practice in one situation turns into an average practice for the industry.
There might not be any existing code for your new platform, but that doesn’t mean you’re free from constraints
You can’t be done unless you know what done means. So how do you know?
When you say you want quality software, what are you really asking for, and how can you get it?
You need to make sure you’re solving the right problem at the right time.
The trick is to know which models to use, and when to use them.
I got my attribution wrong, and you probably did too, but the point is just as valid.
You might need permission, but feedback is more valuable.
You can write bad code in any language. You can write good code in any language. The choice is yours.
APIs are a conversatin with your user. Meet them where they are.
User stories are not about what to do, they’re about how to add value.
Of course the audience is listening. So what are you doing?
There’s a lot to learn from aviation. Particularly around incident management
Knowing when you’re done is just as important as knowning what to do.
There are many types of risks for a software project. New projects/teams have their own in addition.
It Depends is human for the lack of context error code.
It’s good to be DRY, but you can have too much of a good thing
Be careful when looking at aggregate data. If can be hiding what you need to see.
Why do students pass or fail tests, but software tests pass or fail?
What are these forces, and how do they interact?
You might have been wrong, and you can always make new choices, but the decision process you used yesterday doesn’t change.
How you see a problem is just as much of a bias as how you respond to it.
Perhaps oddly, perhaps not, the traits of an effective software engineer have nothing to do with software
You can rubber duck too much, but please, take a moment to think about the problem before you give up trying.
You can’t guarantee forward compatibility, but you CAN make it easier
How can something be proven correct and still have bugs?
What does it really mean when we say it’s the shortest day?
Throughput, Latency, Batch Size, and Latkes
Because what you test is as important as how you test it.
Sometimes you need to say it out loud and to others.
If you ever wanted to know where it all came from, this is where.
Testing and the essential attributes of what you’re testing
Cycle time is ALWAYS important
Some bugs are caused by the things you do, some are caused by the things you don’t do.
A small conference with a big picture
Balancing forces can make for apparent paradoxes
Turns out, there is proof that technical debt breeds more tech debt
Just what is readability anyway?
Is the developer’s journey one of the 7 basic plots?
Trying multiple things at once is NOT faster
How to get from someone from partner to customer
Shipping sooner by starting less.
Just because you can shell out and call a script, that doesn’t mean you should.
There IS a difference between the two. Make sure you’re going for the one you need.
That’s pretty clever, so fix it.
Software development is more than a little like magic.
Primitive obsession sneaks in when you least expect it and makes things worse.
Technical debt is not doing a bad job now and fixing it later.
Why does focusing on finishing rather than starting get more done?
What is Refactoring and when do you do it?
Do you have customers or partners? The difference really does matter.
Don’t blindly copy what others, even successful others, are doing.
Naming is important. Even if it’s applesauce
What are those policies for? Why do we have them and how long should they live?
60 years in, the Unix way still makes a lot of sense
Some kinds of tests you just don’t want to write
Monitoring and Observability are NOT the same thing.
Tradition is more than just doing what your ancestors did
As long ago as 1968, BDUF was a bad idea.
Good habits are good, but there can be too much of a good thing
There’s a difference between delivering often and continuous delivery
How do you REALLY know if something is unused?
Scripting is only part of automation
There is a difference between testing before and after coding
Tests are like cleaning the lint filter on your dryer
There are some quotes you know that just ain’t so
We aspire to uncouple with clear boundaries, but we need to work together
Is it someone’s fault, the system’s fault, or a balance of both?
Sometimes things need to move around a little
What’s an elevator pitch, and why is it important?
The purpose of testing is to increase confidence for stakeholders through evidence.
Visualizing your career progression to manage your career
Bias for action is thoughtful. Bias for reaction gets you in trouble
User stories need to live in the Goldilocks zone. Not too big, not too small
Understanding what scope of influence means in practice
Even thought the 1’s never get worn down, software needs maintenance too.
If you can’t change the error how can you fix it?
Why taking a break is so important to having an impact
Level is really a proxy of scope of influence
Why is planning so hard?
It’s important to step up when there’s a big problem. But the real hero is the person who sees the small problem and prevents the catastrophe.
There are lots of management quotes. Make sure you are using the full quote, not just part of it.
Doing too many things at once will slow you down.
Which one you optimize makes a HUGE difference
In golf you want fewer strokes. In code, that’s rarely the case.
Just what do you mean by PM anyway?