I'm going to attempt a small 🧵 to explain ADHD in computer terms. Imagine your brain is a computer; you have working memory (RAM), long term memory (hard drive), processors (frontal cortex) and an operating system.
The operating system has a process manager which takes care of all the things. Some are daemons and run constantly on dedicated chips like breathing and sensory processing. Others need to be managed to interact with the CPU (the frontal cortex) to be active.
Most humans perform a type of preemptive multitasking where processes can interrupted and scheduled based on I/O waits, CPU needs, and timeslices. You can work on something until you have to go to the bathroom, or you need to eat, or just because it's time to stop.
In ADHD brains the interrupt mechanism is different. It wants to do something, anything really, and when it sees CPU and I/O dipping it assumes a new process needs to be spawned and given priority. It also will randomly terminate processes.
Most computers will defer to the user for what process has priority, the ADHD manager attempts to round robin task switch across all the processes without regard for what the user wants or needs.
Imaging you're using a email app and suddenly out of nowhere minesweeper opens and moves to the front. You didn't ask for it, but here it is, then as soon as you finish one level it opens a new browser tab and navigates to the wikipedia article about the Ottoman Empire.
There are also times when the interrupt mechanism will hand all priority to a single process and refuse to send scheduled processes to the CPU, need to eat? pee? sleep? No! Link can't save Zelda on his own, he needs me!
This style of processing isn't broken, it's just a different pattern. There are times when this task switching is beneficial as not all tasks really need to be given priority. Which is why ADHD folk tend to thrive in chaotic environments that stress out others.
Let me start by saying that I don’t hate mocking frameworks. They can be incredibly useful, and from an intellectual standpoint they’re some of the most amazing and interesting code you can look at. If you want a masters class on reflection and runtime manipulation go dig around in them.
What I do dislike is how they’re misused. I consider myself a classicist or a member of the Chicago/Detroit school of mocking. That means I don’t mock often, and when I do I prefer to use hand rolled mocks because I find they’re better at letting me test state as opposed to interactions. Still, sometimes mocking frameworks can be damn handy and I’m not above using them. More often they’re part of an existing application that I’m working on. The main problem I see with them is when developers don’t stay SRY with their mocking. Every time you mock a method that’s a little dab of glue making it harder to change that method. I get sad when I come into a test and see a chunk of mocking repeated over and over in every test.
User user = mock(User.class);
when(session.getUser()).thenReturn(user);
when(result.getName()).thenReturn(“Stacy”);
You will often find that these same lines are repeated throughout the system in many different tests, sometimes many times the number of invocations in the production code. If you want to change getUser() or getName() you may find that difficult, not due to the prod code but due to the mocker. I've litterally spent days refactoring tests and mocking statements so I could change some method automatically.
We can get around this the same way we stay DRY in our production code, through encapsulation and creating common utilities. In the above example, if this happens in one test we can easily extract a method for it. If it’s in many tests we can do the same but put it outside. I sometimes end up with a set of utilities for common methods. Something like this:
public class SessionExpects {
public static User currentUser(UserRepo userRepo, String name){
User user = mock(User.class);
when(session.getUser()).thenReturn(user);
when(result.getName()).thenReturn(name);
return user;
}
}
Now we can have only one place where these methods are called and if we need to change them it should be a lot easier. We also maintain the existing tests and other usages of the mocking framework. So it’s really low risk, low change, all we are doing is not repeating ourselves, which seems simple, and yet, maybe not obvious.
I had the honor of appearing on 'Software Engineering Daily' podcast to talk about practices at John Deere. Topics of discussion include autonomous vehicles, team autonomy and devops overload
In the weeks since the google manifesto I’ve been thinking about what I see as a fundamental misunderstanding the nature of software development I wanted to get it off my chest.
Is Programming Math and Engineering?
Yes! Of course it is. Where the author fails is in narrowly defining math and engineering to traditionally male dominated professions. Historically and across cultures women have dominated domestic crafts. Weaving, knitting, embroidery, tailoring, basket and pottery making are all forms of “thing thinking” that require high-level problem solving, mathematics and a deep understanding of materials. Yet we do not value them at the same level of men’s work. This is partially due to the more temporal and replaceable nature of these crafts but it’s also because we do not value women at the same level we value men. So we call the things men do “engineering” and the work women do “crafts”. The fact that men’s traditional crafts involve stone and metal, and women’s involve clay and yarn is irrelevant to the skills needed or women’s interest in them. Just ask Hobby Lobby.
Weaving involves configuring complex repeating patterns of information into a machine that renders that information to new forms. (Sound familiar?)
Is Programming Human Language?
Yes! Of course it is. When we program we have several different audiences. The compiler or runtime is one. Other developers that must read and understand our program is another. Some of the worst code I’ve ever worked on was written by coders with poor communication skills. Naming things is hard, composing code into a readable flow is hard. By applying basic composition skills to our code we can help those that come after us.
Larry Wall, the creator of the massively influential Perl programming language has spoken and written extensively on the connection between human linguistics and programming. Perl itself was informed and designed with linguistic principles.
Is Programming Applied Sociology?
Yes! Of course it is. As all programmers who have been around a while will tell you. Writing the right code is much harder than writing the code right. Programmers must be part of the process of gathering requirements and empathising with customers. We have to work hard to ask the right questions, give meaningful critiques, and understand the problems that need to be solved.
Is Programming STEM?
Maybe? My personal feeling is that part of the problem of getting women and men who do not conform to stereotypical “Big Bang Theory” nerdom is in the public perception and marketing of the career. We are working against a harmful and counterproductive vision of the coder as a socially awkward genius sitting in a dark room. Most programming isn’t writing router software or physics engines. Developing software for humans requires a high degree of general purpose problem solving, teamwork and empathy. Many of the best programmers I’ve worked with did not come into programming through traditional educational paths and I’m not convinced that grouping programming with math and engineering is beneficial to it from a marketing perspective. Perhaps it should be in business, design, or even on it’s own.
We are also working against a toxic and misogynistic culture that drives the women who do want to engage out. The most baffling thing about the manifesto is it’s choice to basically ignore the voices of women who will tell you why they left. It’s not a mystery we need brain scans to find out. Just ask.
Velocity is a largely meaningless “measurement”. It’s relative, it’s based on estimation (which we are all horrible at), and it’s subject to all kinds of external forces that impact teams.
A much better thing to measure are the forces hampering our teams from delivering. I like to think of this as viscosity. In science, viscosity is a measurement for how fluid a liquid is. Water flows faster and easier than honey. Similarly, our teams will go as fast as they are capable of. The real issue is finding what is slowing them down.
I came up with an entirely unscientific method for calculating a team’s viscosity. In the course of a team delivering something to their customer:
Start with 1 point
Add 1 Point for each external team or person (not on the team) you are dependent on in order to deliver. This could be DBA’s architects, operations, security, marketing, etc etc. It could also be another team responsible for some other part of a feature. Maybe your teams are split between “back end” and “UI” for example.
Add 1 Point for each required technology needed that your team is not proficient in.
Easy huh? Your goal is a value of 1. Obviously not all values of 1 are equal but it should give you a target to work on. You are free to play with the point system. Maybe dependencies outside of your company or area cost more?
Teams that are self sufficient are going to be faster or at least be more responsible for their own speed. What would it take to get a team with all of the skills and people needed to deliver?
Of course teams impact other teams. Viscosity is all about how a liquid moves in relation to itself. What’s really fun is to take all of the viscosity points for an organization and cross them together. So rather than just run the points of each team, inherit the points from your dependencies. So if your team is dependent on a team with a viscosity of 5 then you now also have 5 as well (plus whatever else).
Map this out and you will start to see the big bottlenecks of your organization. You could create a nice dependency graph and watch as it explodes. Teams that should be really fast suddenly look slow because of a web of other slow teams (usually built to “support” them).
