Unpacking Technical Decisions
Every day, we make hundreds of small technical decisions: what’s the best way to implement this? Where should this function live? Is this library worth using? Occasionally, we make a larger decision: would a different framework make us more productive? Should we rewrite the whole thing in C?
No matter what scale we’re talking about, our decision making leans heavily on past experience, our community, and usually a search engine. But beyond that, the process is mostly opaque. Two programmers, given the same data, often make different decisions. We all want to be the one who’s usually right, but…how do we get there?
Let’s unpack our technical decision-making process, and see what we can learn about getting better at programming. Is mastery really something you just have to wait for? Can you accelerate it? And just what does “productivity” mean, anyway? We’ll take a tour of the science and figure out how we can apply it to the decisions we make every day.
“I can’t see you too well – it’s very bright. I can just see your glowing apples…”
Awesome bit of geek social hacking: Sarah literally calling to people to come talk to her during breaks, “even if I’m on my phone!” …because she doesn’t know people here, it’s a long way from her usual conferences.
…
Sarah started in backend but now does about 50/50 Ruby and Javascript. Interesting shift over the years! This talk is about how we make decisions about code; and how we can get better at that kind of decision. While the talk uses Ruby examples it’s not specific to Ruby… but the talk is also about humans; and that’s the hardest stuff we do. Human relationships are much harder than code.
Code and humans are inseparable. You can’t just have one or the other.
[Conway’s Law: organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.]
You can tell a lot about programmers by looking at their code – how much pressure they were under, how clear the scope was, what their coding background is (backenders write very different javascript than frontenders).
There are some key groups that turn up at conferences like Fluid… backenders, design+ux, and frontenders. But although they are very different in many ways, but they also all end up with the “which js framework to use?” question.
There are absolutely tons of options out there. But it’s not specific to Javascript, all technical groups have these quesitons. Which data store, which x, which y.
There’s heaps of data; there are always pro- and anti- blogs or presentations for every option. Our job is to make a decision and it is scary as there’s a cost to that decision.
Many companies just live with the drag of past choices. However this is a great way to get disrupted by a startup who can move faster than you. It’s usually not a catastrophe, more of a slow decline.
Because we don’t make these choices often, we don’t get the benefit of repetition – which is a key way we learn. So we don’t have a lot of opportunity to get really good at making these decisions. Think about the 10000 hours meme – even though it’s mostly untrue, there’s a kernal of truth. We learn well by repeating – practicing – and evaluating the outcome then trying it again.
Decision frequency: we don’t choose languages very often, we choose libraries on github more often and we choose names for variables all the time. The process is usually pretty opaque – we usually can’t explain our choices very well. We tend to say it’s gut, or experience.
How do people evaluate github projects? They usually start with the readme. You could also start looking into the API, look at the style of code. Commonly people look at the activity levels on the project, ask around for opinions of coworkers/peers.
Issues with this? Not everyone evaluates the same way; lots of the data is social data rather than technical data; not everyone does as many evaluations.
You can split it up:
- Interface – readme, use gem
- activity – commits, issues, Prs, etc
- popularity – community strength
- accessibility – reading the code, how accessible is this to my mental process, my style of code?
The Mei System:
| internal | |||
| people | Accessibility | Interface | project |
| Popularity | Activity | ||
| external | |||
Many times the options will rate pretty evenly on all counts except accessibility. The different options will often feel different, and do you identify with the style of the code?
Angular feels very familiar to backend (Java) devs. This means there is less cognitive load as it doesn’t require the java dev to learn an entirely new programming paradigm. Of course to non-java devs it’s pretty disorienting to learn.
Ember meanwhile feels familiar to Rails devs. Backbone is older and will feel familiar to people who are used to a more traditional rending model, where JS works on top of a server-side rendered page.
…
So, accessibility can be very hard to evaluate – partly because people don’t realise where the frameworks come from. The frameworks don’t really advertise it, consumers may not realise their own bias.
So how do you see the bias? You don’t have to necessarily know what the bias is, but you’ll feel the results. How hard does it feel to use it?
Plus you don’t always want to choose the easiest option for accessibility – sometimes the team is ready and wanting to learn a new way, sometimes they don’t have the time or energy.
…
[Tweet: “the only reason nimrod isn’t adopted instantly is because people don’t evaluate things logically”]
[“A change of perspective is worth 80 IQ points.”]
…
Q&A
Q: how do you balance the New And Shiny aspect?
A: part of a project’s success is how enthusiastic people are. If you have people who are bored and frustrated, it will be hard to retain them if they can’t work on something fresh and new. So it has value to the business to keep them!
