I've found it increasingly difficult to tweet. Everything has it's caveat. Everything is grey-ish. I find myself wanting to provide multiple asterisks with contextual information, disclaimers and clarifications.
It’s not universally applicable, of course. But to me, in complex environments, particularly where people are involved, I find these practices generally helpful.
This is a common misunderstanding I encounter, where the sprint is treated as a delivery cycle rather than an inspection cycle; it’s all about empiricism. I encourage people to read the Scrum Guide :)
Sprints are harmful! They lock people into a plan, even if "just" a two weeks plan. It halts collaboration with others in the name of "protecting the sprint goal". The only possible sprint is a 1 day sprint.
But, I also find it useful to take a step back, looking at the latest aggregate of changes, inspecting processes, interactions, etc. on a more holistic level every couple of weeks.
To me, this setup eloquently straddles the line between long- and short term.
GitHub has a talk from 2013 where the Ops guy says:
"We don't have dashboards. If something goes wrong, the alerting system generates a chart showing the error, screenshots it and then drops it in the ops channel"
I think about this quote every time I see a dashboard.
I’ve been guilty of this for ages.
The last couple of years I shifted towards simplicity. Now I enjoy software that is easier to maintain, easier to change, and just as reliable as before. The longevity of the software is through the roof.
Over-engineering is such a huge problem in our industry. It's kind of incredible how often I look at projects that have so much unnecessary complexity, over-abstraction, etc. that makes it impossible to understand.
Simplicity is a feature. Showing how smart you are is not.
One possible downside; if I expect an option to be available and it isn’t where I expected it to be. “Is it just not available, or could they have named it something else?”
I’ve found simple lists works better given that the list is in alphabetical order. Easily scannable, clear on available options, no need to reach for your keyboard.
I tell my students to avoid using select boxes.
It’s often better to go for radios.
Their response: “but it makes the list long”
Yep, but that doesn’t necessarily mean it’s bad UX.
Here’s one question I designed doing just that.
No issues in user research whatsoever.
For the startup CTOs who think they need to handle 100k concurrent user.
Google does 5.9M searches per minute.
That's 98.3K per second.
You aren't that big.
At the same time: a sharp axe, a deliberate routine, etc., etc., can increase your effectiveness and efficiency many times over. That’s also what to benchmark against when considering and evaluating said activities.
So, once again, the keywords here are “too much”.
Hopefully they’re merely misguided; wasting talent and time on things that are secondary.
I mean, if you’re a lumberjack you occasionally have to sharpen your blade, but the keywords here are “too much”: obsessively attending to the axe is not what you’re hired to solve.
🌶️ Programmers who care too much about the shape of the code do so because they can't actually program.
They get their sense of achievement from how the code looks, rather than from what it does.