Developers spend most of their time figuring the system out
lepiter.io
lepiter.io
How? "Deploy personal + company resources as appropriate to get the job done together" - however they damn well want to in that framework. It is between them. The pair could:
Use a whiteboard for 5 minutes every 3 hours and go their separate ways otherwise.
Sit together hunched over a single laptop.
Work from two entirely separate locations with collaboration software so they can see each others cursor and typing as they voicechat.
I mean, isn't it all about simply getting along and getting a job done?
Hard problems are quite rare, most development is mundane.
When facing hard problems, generally related to non-obvious bugs, there are many ways to solve them, and yes taking time off to think about it separately is absolutely one of them.
This isn
So yes, you're correct.
It's the 100% pairing, or worse, 100% mob programming (up to six people with one screen!) that I can't believe would ever be more efficient than the programmers working independently.
Sure, have a party and mob-program for fun for an afternoon, or solve a particularly sticky problem that way, or use it to transfer knowledge about the system to the wider team. Have a blast, and teach everyone something useful at the same time. By all means.
Just don't pretend (as pairing/mobbing advocates do; not you) that two people sitting at a computer can be as efficient at day-to-day coding as two people coding separately, unless at least one of the two is a junior or near-incompetent developer who would contribute negative productivity on their own.
But you are right that voluntary pair programming can be a good thing, so we shouldn't ban programmers from pairing if they want to. But the discussion is whether it makes sense to force programmers to pair program. I really doubt that for example pairing John Carmack and Linus Torvalds would be productive, and that is the kind of personal pairings you get at work.
I absolutely can pair for such an event. I'll pair for knowledge transfer. I'll pair for fun. If every second counts, or if the goal isn't maximum productivity throughput, the sure, pair away.
My point is not that it can't help for world-class developers, but rather that two world-class developers working on routine coding are absolutely not more efficient than two world-class developers working separately.
And people who advocate for pairing typically advocate for 100% pairing. Which can be fun but it won't be more than 2x as productive as two world-class developers working independently.
Lets say, hypothetically, that you can use it to ramp any programmer up to being an expert on the system. Maybe that takes two months? Or even six months? Once you have a team full of experts, you're now spending two programmer hours to do every bit of work that could have been done in one programmer hour by a single expert.
Unless you have such incredibly high turnover that the period to transform a developer into an expert is close to or less than the average tenure of an employee, in which case your team has other issues that likely need to be addressed, because why are people jumping ship so quickly if it's such a great place to work? (For example: If it takes six months to produce an expert, you'd need to have an average tenure of less than or equal to six months to really benefit from pairing; anything more and the 50% performance penalty has to eat into your overall productivity.)
On top of that, I have never been at a job where it's taken me more than a week to get up to speed on a system, or at least to the point where I can simply ask the occasional question of the experts on a team to get me unstuck. Even if the average developer took a month or two, pairing beyond that point is simply fun and not more productive than two programmers developing independently.
Unless one of the developers is otherwise likely to produce negative productivity on their own, I suppose. I've worked with that kind of developer as well, and the right answer is to eject them from your team, not pay other developers to babysit them.
Teaming up for training is absolutely crucial at this time.
Unlike most programming "best practices" or paradigms, there's actual empirical evidence that pair programming is "better". Fewer bugs, easier to read code, shorter review cycles.
My guess as to why we don't see more adoption is 1) most developers aren't that fond of it, and 2) most managers do some quick gut check mental math and assume 2 programmers + 1 computer can't be equal to or greater than 2 programmers + 2 computers, that's nonsense, actual evidence be damned.
edit to add: I agree with commenters that pairing is more demanding/draining than solo work. I shudder at the thought of anyone trying to pair for 8hrs straight, or "all day every day 40hrs/wk". Nobody solo programs like that either though.
But you also have 2 developers using 100% "of their cpu" during that time, which is really unsustainable for longer periods.
Meanwhile, some of that research is pretty easy to deflate. From the first article, for example:
Students prefer the 15% overhead
That's right -- they used a survey of student experiences to draw conclusions about what works best for senior developers well into their careers. As the authors themselves put it: "We feel that this is a strong indicator of the satisfaction of pair programming."
I don't see how they can call this "strong" evidence of anything.
When I do pair, I only work for 3 or 4 hours that day total.
The best model would be four hours of pair programming and another four of paying those programmers to take a long lunch, a nap and a walk. Those 4 keyboard-hours would probably be as productive as 16 keyboard-hours of the same programmers working independently for a full day, if not more. And unlike full time pair programming it would be sustainable.
So we have to "play" the game of looking busy and appearing productive for appearances.
If it became a required part of daily work in my company, I don't think I'd be around for long.
For what characteristics of problem is pair programming more useful, when such problems arise? Is there a pattern to plan for?
My opnion is that people need time and practice to aborb. Everyone has there own way. If you are pairing everyday for no other reason then company policy, it sounds like the worse place in the world to work.
No it doesn't, bugs happens since there is much acceptance for bugs, programmers develops just enough awareness of them to get the bug count to maximum acceptable levels. If you take two programmers who both learned to get there on their own and have them oversee each others work, you reduce the bugs temporarily, until they adjust their attentiveness and conscientiousness downwards to account for it and the bugs rise again until they are at barely acceptable levels.
You see temporary improvements like this happen everywhere. Researchers love it because it makes it trivial to publish papers, but these results usually doesn't scale, and even when they do scale the effect is significantly smaller than originally advertised.
While I agree with that, the cost-tradeoff is not worth those improvements (which are slight). Feel free to post to the studies that you find compelling.
I've been programming at various levels of abstractions and different stacks for 20 years. I often have very good intuition on diagnosing and solving technical problems. It's very hard to verbalize this, especially to people without the same background, it's intuition built on hours and nights of pain and debugging/googling/prototyping and I often need to search and REPL/prototype things to know I'm going in the right direction.
So I waste time dragging the other person along my mental path, and when I go into a wrong direction the cost is also increased by having to explain what I'm doing + the other person usually being annoyed at being dragged along for something they barely understood and it ends up being for nothing.
"Keeps people on task" seems like management-think adjacent to "butts in chairs in an office" requirements: There's a fear that someone might be "wasting" time by being distracted, when you seriously need to contemplate problems sometimes.
I'd need to see that "actual evidence" that we're allegedly discarding. Two programmers with two computers clearly could produce twice the productivity if they're both strong programmers. When I've been pairing with people I simply do all the work. I might get 1-2 comments per hour about a missing semicolon that I would have discovered the moment I tried to build. The claims of the pairing advocates are pretty hard to believe, and I don't see extraordinary evidence to back their extraordinary claims.
As I intimated above, the only way it would work is if the developers are junior (or mediocre) enough to be prone to contributing 0.5x or less productivity left to their own devices, so that the two developers' inadequacies at programming complement each others' and you get a 1.5x productivity out of them combined or something. And I do suspect that companies use that fact to hire less competent developers and make them at least reasonably productive; Pivotal does 100% pairing, and sells it hard, but note that they're paid per developer hour and so actual productivity per-developer isn't what they're necessarily what they wanted to optimize.
As to your Edit: The exact thing I'm objecting to is 100% pairing, which is practiced at some companies like Pivotal. Or worse, 100% mobbing, which is more than two people at one screen.
If you have a team of experts, and you want to keep them all experts, it's much more economical to have two people learning the new code as it's being written. Theories about what might or might not be helpful have very little value until tried in the field.
Would anyone ever say you only need one copy of the code, because backups are inefficient?
To give a more concrete example a pair programming session might avoid putting in foundational code that ends up being a bad design choice and slowing down the team by 1% forever. Maybe at a cost of millions. That 1% will never show up in any OKR or KPI that just basically measures superficial stuff about the status quo (bugs raised per quarter, features delivered on time etc.)
I mean it is like we forget we live in an age where still someone smart coding at their laptop can launch a million dollar business.
If you can figure out a smart “hot take” way of working, like maybe pair programming it is a big competitive advantage.
To the point you probably wont find a job for a company that works that way because they can more than make do with a small team.
You’re forgetting that it’s impossible for any one person to keep all the details of even a medium sized code base in their head.
I imagine the initial “planning” phase of implementing a change would benefit heavily from pair programming because it avoids the issue where you write a bunch of code to find out that it doesn’t work because of this one detail that you forgot.
For the learning (“knowledge transfer”) aspect, though, I think you’re right that it’s possible to reach a point where writing the actual code (not the design) as a pair is not worth it.
It may not be as efficient, but it can be more productive in the long-term if you're better insulated from staff turnover, for example. Making engineers more replacable could also contribute towards lower wages (more able to hire beginners and make them competent, reduce leverage of existing staff).
While you can type a lot more by having two people type in parallel, some programming is much heavier on the problem solving aspect of things and those types of problems are sometimes completed more rapidly with two people working together than with two people working separately.
And also, pointy haired bosses and accountant don't mind pair programming all that much. Normal average developers with normal average psychology do mind it, object it, hate it.
The times I’ve been involved in pair programming it has been a disaster. I need time to sit there and think and process while the other person is getting bored and wants to keep going or they start to talk which ruins my thinking so I have to start over again.
In my current job, everybody is remote and you can't even play foosball with people on your team.
But at steady-state, it becomes a drain on efficiency.
In my experience, forced pairing is something that a small percentage of people love but it burns most others out. Every company I've seen try to force full-time or even most-time pairing on people has quickly lost a lot of their good developers. Although on the plus side, they at least have a system in place for quickly ramping up new developers as they join to fill all of the openings.
Personally, whether or not I can do pair programming has a lot to do who I’m working with, what I’m doing, and what kind of day I’m having. The same thing goes for test-driven development. I have ADHD and short-term memory issues.
This causes me to work by feel on some tasks because I don’t work on problems in order. I visualize everything like a house of cards. I see everything at once and load random parts of what I’m looking at until I see the whole thing in my minds eye. (Because I have three logical registers on a good day.)
Asking me to explain my thinking requires me to restructure the process in reverse and put it into a linear thought that can be understood by someone else. Which half the time dumps all of the registers in my short term memory. Meaning I don’t understand what I was looking at. Communicating with neuro-typical people is frustrating, mostly because I try really hard to communicate clearly. (Good communication means better relationships with coworkers and less wasted code.)
Despite the complete chaos in my brain, I write extremely good code (by other people’s measures), because I think about readability, algorithmic complexity, side effects, testability, and a thousand other minor details at the same time. Tests come in once I’m happy with the structure. (I hate working without clean understandable tests!) Then I refactor to clean up the code and comment to explain reasons why it was written specific ways, so coworkers (or future Kayodé) don’t want to murder me.
If this comment is a bit rambling, you know why. :)
Granted, code requires far more details than many conceptual explanations, but it is still one.
Discussing code for linked lists for example, having the box and pointer notation for what happens and scenarios very helpful!
[1]<->[2]<->[3] to [1]<->[3] means changing [1]'s and [3]'s pointers and freeing [2]
When I learn about and talk about a system a visual representation of the flows of data and function calls is playing in my head. I get an overview of the system and what it does. Think "mental model". I "see" that this service calls that service to get that piece of data, which it gets from that database table and it all flows over there to do that and suddenly it all makes sense. I recall those high level flows for a very long time too and I have no idea how I do it. It just happens. I hope my mind keeps doing this for a very long time still.
I can talk about it and it makes perfect sense to me. There are other people at the company usually that share the same knowledge and understanding and if we speak a similar enough language we can communicate well. And then there are people that do not seem to get this level of understanding, even after prolonged periods of working on the same code base. Ever. When you ask them to explain to you how the systems and modules interact, they can't.
And then you draw some simple graphs of this service and that service, and this database here etc. and it finally clicks for them. They could not synthesize this from code or written text. They only ever saw the local view of the module they worked in. Overall, more abstract flow of information and modules was lost to them. You have to actually visualize it for them.
Note that I am not talking about "visual programming" as in drawing UML like diagrams and such to actually program. It's purely about showing data flow and call stack and such. Usually I don't need to draw this for myself as my head does it for me and it works really well with statically typed languages without any magic going on where I can just have the IDE navigate to exactly the right places, find all the code references quickly and accurately etc. One time (a looong time ago) I actually threw together a quick script to generate a graphviz file for the call graph of some system based on some proprietary database's stored procedures that I had to quickly come up to speed with and that nobody was there to explain to me. I think it printed out to like 15 pages that I taped up on the wall next to me just to make sense of it. No IDE support to click through from one procedure to the other.
Google “crazy conspiracy board meme” and you’ll have a good analogy for what’s happening. If I start writing it down, things randomly disappear from board. Which requires me to look at the gaps and fill in the blanks.
You can imagine what this looks like from the outside. My dad has interrupted me so many times with “get to the point” and the only response I have is “working on it.”
The funny thing is… I’m an author and prefer to work with text.
- Learning CBT from a book with the help of a therapist to guide me. https://www.amazon.com/Feeling-Good-Handbook-David-Burns/dp/... The core of it is in the first few chapters. Never read the later ones once I got the concept.
- Learning how to have realistic expectations about what I can do day after day.
- Prioritize self-care and optimize for long-term performance over short term success. This includes going to bed earlier than I want. :(
- Working with my manager to have the proper accommodations. In my case, strict 40-hour work week, no work interruptions outside of that, and time off as needed.
I’ve needed accommodations less since things have evened out, but I’ll never be able to do on-call.
Motivation- you need to actually align your tasks with an actual concrete personal goal or sense of accomplishment. And be invested in the work. Lacking that, you'll be dependent on external stressors to get anything done, which will reflect poorly on you if it gets to that.
One of my issues with motivation is what you mentioned: I really really struggle to get invested. Things that are "work" seem to live in an anti-motivation bucket, regardless of how organically interesting they may be to me outside of a work contest. I'm in my 30s now, and I've been doing this my whole life and it is killing me. It takes a tremendous amount of effort and an extremely imminent deadline to get me to start anything. This (ostensibly) runs completely contrary to my self-concept and value system, but the motivation problem permeates every fucking inch of my life, and always has.
I can read this back and recognize a defeatist attitude, but I don't know what else to do.
Any time I get too distracted and drift off there's someone to nudge me back into focus. Occassionally I'll have to apologise and just say, "Sorry I didn't catch any of that" which sometimes takes a lot of understanding on their part to not be offended.
There are some days where I struggle to explain things which is very frustrating especially for architecture type issues. I also struggle to actually build anything from scratch, and definitely have a brain more wired for destruction than creation.
Secondly, you need to find an understanding workplace. The best places I've worked have been understanding of the fact that some weeks they'll get less out of me than a freshly hired junior because other weeks I'll do some very good work.
It helps if you can have a niche, and helps if you can start off making a good impression. For me that niche is more of a bug finding and security focus. On weeks I'm feeling very motivated I can spend my extra energy being useful finding security holes and general bugs. Good managers will see the value from that.
If you tasked me with writing even the most basic "todo list" web-app from scratch you'd probably find me after a week deep in analysis paralysis still deciding between frameworks having not written a thing, but give me the simplest "todo list" web app even one that's too simple to have bugs I'll have found something wrong with it before the day is out.
But everyone is wired differently, so your niche might be the building side. Just work out from experience what your strengths are and lean heavily into them, or at least strong enough to get a reputation than you're good at your job, but not so heavily you get pigeon-holed in a role.
And if it's just not working for you, don't be scared to just quit and find somewhere else. There are good and bad workplaces, and a surprising amount of advice is from people who have only ever worked 1 or 2 jobs at most so don't actually necessarily have the experience of different workplaces to be able to back up some of their assertions so take all advice with a pinch of salt and work out what works best for you.
This has helped in two major ways. I've let go of the idea that the hyper productive days are my natural state, and that the 90% of the days that aren't there are some kind of failure. I've also built my career to avoid having daily accountability and prefer weekly/monthly.
That mindset shift, separate from the daily "how do I get stuff done" tactics, has really helped prevent the kinds of negative spirals that adhd can put me through.
I think the GP post (GGP?) about the utility of sharing expertise is a good one, though I think that can be done w/o it being 100% all the time as well. It probably also depends on the nature of the tasks and complexity of the system. There may be jobs that really do optimize better w/ a lot of paired programming, and I'm just not a good candidate for those roles. We all have different niches in which we achieve our best performance.
Pairing may be good to some degree for knowledge sharing but it works against good architectural design, which requires the kind of holistic thinking you describe, as well as kind of micro-iterative whittling away at the problem that interactive pairing couldn't ever achieve. In addition, the n^2 communication lines yield the worst effects of Conway's Law https://en.wikipedia.org/wiki/Conway's_law
Nearly all of the computational problems we face in industry (save a narrow class of specialty problems) can be pretty easily articulated in the "macro" sense: "oh, we'll just have this distributed actor invoke that one and he'll reply with the blah, blah state".
Look, we just paired and collaborated on a design, cool! But the reality is that none of the hard parts have been solved. The hard parts are always the unanticipated errors, edge cases, invariant violations that beset every system--a large set of issues that need to be made airtight when it comes down to actually putting the code and tests together, and these require the holistic thinking you're talking about or either you get subtle bugs or otherwise a mess is made in the code.
As an industry we've gone so hard on coming up with social processes to "knowledge share" (pairing etc) and do things like audit for defects (code review process), but all of these are ultimately compensatory measures for bad design and bad code; and, in fact, as you suggest, they kind of encourage and trend toward bad code.
A different approach to building systems socially would focus on the code being decoupled and articulated such that the barriers to entry would not _require_ pairing and these other processes. Decouple and compose components that can be understood at face value and in situ.
But this is very hard and requires extensive practice and expertise, something our industry isn't keen on talking about. We like that quick race to "expert beginner" wherein we can say "Phew, now I'm an expert". So instead of focusing on mastering these we go for least-common denominator processes, which if you think about it is what pairing, and many of our processes are,- least common denominator.
The truth is we're social creatures, so I don't think we'll ever get out of this state. Social processes will win not because they optimize the problem space but because most of us love and crave the interaction. My only lament is that we don't call the spade a spade and we try to argue that these processes are necessary for optimization when they really impeded optimizations and create downstream frustration and limitations.
That said, there are definitely cases where sitting back and thinking through a design is a really good idea. In my experience, it's 1/10th of the job.
By domain expert I mean someone who has worked in a single domain for many years. Lets say you have written healthcare backend software for 10 years, then if they tell you to design a new healthcare software system then you will be able to predict most future requirements the system will have even if they don't spell those out explicitly to you. Sometimes laws changes and you have to redesign stuff, but having to adapt code due to new laws isn't a common occurrence.
Edit: And 10 years in a single domain really isn't a lot of time. In a sane world you would be called an apprentice until you reach that level, that is the only way to make robust products. This is how almost every other field works, but in programming people seem to think that such expertise is impossible, at least at scale.
Only if changing requirements are a requirement :)
IMO, pair programming is most useful for short design discussions and mentoring, like explaining a better way to architect a feature to a junior engineer. I look back on these experiences fondly, and this type of collaboration helped me grow a lot as a developer.
I don't feel like I get the concentration and focus required to "put the whole code implementation in my head" when I'm pairing, so I don't really see how it can be used 100% of the time to build systems efficiently.
And regardless of whether it's a good way to work or not, many engineers just won't want to have someone looking over their shoulder 24/7. That kind of environment would drive me mad. I need to be able to drown out the world and bury my head in the code, and most of us don't work on code the entire day. I like having the freedom to read an article or browse the web for a bit whenever I want to fuck off.
Pair programming and mob programming are definitely not for me, and there's no way I would take a job that requires doing either most of the time.
That’s a fun way to put it. When encountering the usual brain–computer metaphors, I’ve always felt like I relate more to the Turing machine scanning over its strip of tape.
I couldn't help but feel my soul being slowly crushed as I read further on their description of the daily activities. Needless to say, the filter indeed worked out. As someone with ADHD, I couldn't last a single day on a job like that.
Culturally traditional management is biased to create the 3 struggling engineers scenario because most management strongly believes that people working on many tasks in parallel is peak efficiency. You see this manifest in places that run the Jira + PR feature mill. Staff that complete lots of jiras and have lots of green dots PRs in their GitHub profile are considered "peak performers"
The fortune 500 is littered with companies full of this anti-pattern. Less so each year though, because if amazing execution on digital transformation matters to the business, to the extent those 3 struggling engineers execute poorly, the competition slowly eats the incumbent's market share.
I love it and it's helped get momentum on things which would typically just sit there. BUT, 30 minutes is definitely my maximum for something like this.... even if we did something minor like make this meeting 1 hour long - I would dread it.
Context: we do have an engineer on-call (on a weekly basis) and they will respond to urgent sentry errors, but the above helps sentry errors with less urgency get moving without being a total buzkill for the on-call engineer to look at ALL of them.
But it does quickly lead to exhaustion.
I've been in a team that does this. I did appreciate the knowledge share from the expert the first month despite the fact it completely drained me. After awhile, I hated the whole thing and dreaded going to work. I get it works for some people, but I know it is not for me.
> on a zoom call
This would make this about 10 times worse. I wouldn't last a week.
Those grades and work experience were quite valuable to myself.
There are protected classes/categories that can't be part of the employment decision, but outside of those, the employer is free to set whatever criteria they want for the position.
If I run a plumbing company, I could say "all of our plumbers must have a computer science degree," and I can't imagine there's any legal reason I couldn't do that. I'd certainly have a recruiting problem, but not a legal problem as far as I'm aware.
So in the case of plumbers, if a plaintiff can show that you are hiring fewer women because women are less likely to have CS degree—then you would need to show a “demonstrable relationship to the requirements of the job” for a CS degree.
However, this isn’t an issue for software developer positions. A CS degree doesn’t have to be absolutely necessary to be able to perform the job, it just needs a demonstrable relationship to the job requirement. There is also already precedent that a degree in a related field does meet that requirement.
Thanks for both of your comments. The mob programming sounds like I would be depleted way to fast.
To summarize: there are three roles, Typist, Navigator, and Support.
The Typist is not allowed to think. They are explicitly described as a "smart input device". For the most part, only the Navigator is allowed to think. They tell the Typist exactly what to type, and the Typist must follow everything the Navigator speaks, to the letter.
The Support only looks over both their shoulders and sets a 10 minute timer after which the roles rotate. Yes, every 10 minutes everyone switches roles.
When working in person, one thing this selects for is people with perfect vision. Elderly programmers need not apply!
Why do I say that? Well, I have computer glasses that let me see my screen perfectly even at my age. This applies to anyone over 40-50: if you don't have them already, I strongly recommend getting a pair of single vision prescription lenses tuned for your normal distance from the screen. Since I use a laptop, these glasses are set for a 20" focus distance. I have two external monitors (one landscape above the laptop, the other in portrait mode to one side), and I keep those at the same 20" distance from my eyes. It is glorious! Everything is in focus, all the time.
If we're sitting around a desk, it's almost certain that I won't be able to read what's on your screen, for the simple reason that it won't be at a distance that brings it into focus (probably much too far away).
Oh, and you may like dark themes and tiny fonts like all the young people use these days. So even if it were at the right distance I wouldn't be able to read what's on the screen.
Mobbing on a Zoom call mitigates the focus distance, but the dark theme and tiny fonts would still mean I can't see your code.
And webcams are supposed to be on all the time so your fellow mobsters can see your face. A nice sentiment, but two problems:
1. I can't work sitting. If I do, I fall asleep after a while.
2. I can work standing, but not standing still! (I'm no John Carmack, who can give an hour long talk without moving a muscle.) I have to move around in order to think and stay alive. So I would constantly be walking in and out of camera range, or stretching, or wiggling around on my Fluidstance balance board, or just looking out the window for a vision break.
A more delicate problem: Sometimes older people need to take more frequent bathroom breaks, and the timing may be unpredictable, especially for someone like me who eats a lot of fiber for intestinal health. Sorry, I may not be able to just "hold it" until the next scheduled mob break. (Apologies for the TMI.)
This whole thing is an ADA compliance lawsuit just waiting to happen. (And no, I'm not going to be the test case; I have no interest in working for a company with these practices.)
Drug your employees so they appear to be working the desired hours. I can see ethical problems with that idea. The employer should at least be dispensing the drugs for free as a "benefit".
That said, I would never want to join a company that has phrases like
> The mob disbands, either to sleep, or to their individual work
and
> [...] full 8 hours of programming [...] minimum expectations [...] additional time is expected to be put in
in what is basically their job description. Also, six to eight hours of non-stop webcam is horrible! https://news.ycombinator.com/item?id=24718640
I went the other way. 42in 4K TV placed further back. Big font. Zero eyestrain.
The main trick is that you have to set up the TV in "Game Mode" to turn off input processing, and also turn off stuff like overscan.
Obviously this setup may not work in a office cubicle or other space-constrained space.
Works fine for in-person reviews in the time of Covid, the other person isn't hovering over my shoulder either. They can stay way back and still see what's going on.
ADHD medication is excellent from a patient’s perspective. The first-line ones are almost immediately effective. If you don’t like what they do, you can just stop taking them and try another one. In less than a year, you can try most of the known-working medications.
Even if nothing comes of it, at least you know. Knowing is half the battle. :)
If you think you may have ADHD, definitely worth it to understand more about ADHD and a diagnosis will help those close to you to understand your behavior.
And note: it does sometimes make you feel like cheating or something… you will have to arrive at your own conclusions. Suggest a good therapist to help deal with it.
Diagnosis can be emotionally helpful— they’re often done by neuropsych evaluation specialists but you should talk to a psychologist or psychiatrist first because evaluation is a few grand, most insurances won’t cover it if you don’t seem very likely to be diagnosed including DSM-V criteria like having significant life changing symptoms before age 12. The testing itself is a few hours of tests designed to push you to your limits for things like working memory, impulsivity, and reaction time. (I was waiting for the tester to say “Reaction time is a factor in this, so please pay attention.”) Parts got frustrating but not like Megaman frustrating.
Depression and/or anxiety are commodities in 80% of those afflicted, so that’s worth paying attention to also.
Your partner is worried. So shift the work/life balance to have more life with your partner. Trust the team at work to understand.
Diagnosis from other people does lead to prescription drugs being offered. If someone reading is using chemicals, please pay close attention. Some doctors attempt to prescribe drugs in increasing quantities. That is not the path to sustainable balance. Medications are useful in an ambulance or hospital, they do help in emergencies! But they're not intended to be used routinely for a healthy life.
Peer support is best. Finding humble, open-minded peers can be challenging. The CouchSurfing (now BeWelcome) community is very open-minded and humble. Many church friends are humble. Teaching from the Bible is a reminder of how none of us are perfect, yet God forgives, and shows grace, mercy, and peace.
Some companies try to force concepts like pair programming, mob programming, etc upon their "human resources". It works well for people who like talking & body language, but not for people who prefer reading, typing & listening to music. Personally I prefer reading & typing, and that's why I use Hacker News.
You're not alone, you're welcome here. Interruptions are OK despite the cost of context switching. Diagnosis is not needed, you've already found help. I pray that God will bless you with peace in your personal and professional life, and they'll all catch up to your high-frequency genius ideas soon :)
But don't stop with a diagnosis, get some coaching from an ADHD specialist. There's so much more to it than just attention -- emotional dysregulation, time-blindess, executive function impairment.
It's a whole thing. But with support you can cope with most of it. And most importantly learn to separate the condition from.your character.
Wildly different experience compared to mob/pair programming all the time.
I mean to each their own, but companies - and fellow developers - need to stop forcing others into their way of working. Having One True Way of doing things is always bad. But yes, this may mean there will be a divide in your company / teams, where one part prefers solo work while others prefer group work. Deal with it. Compromise. Let the extroverts work on their own for a while, and the introverts do some pair programming, but don't go all in on one or the other.
This isn't just true with programming. If you like to do things solo, then don't become an airline pilot since they always work in pairs. There are plenty of other places you can work as a solo pilot. Airline pilots work in pairs because, for that type of work, there are advantages to doing so. If a company wants to "go all in" on pair or mob programming, there may be very good reasons for doing so and trying to have a split culture doesn't always work.
I've been following a very similar path as you describe in your last paragraph, and I'd be very curious if there are other similarities that differ from how others write code.
By chance, do you struggle with eating sounds in offices to the point where you panic?
Thankfully the CEO of the company wasn't much into it, so he forced our pointy-haired boss of a manager to make it optional.
The whole team unanimously decided to never do it again.
I like continous pair programming, but not because I actually continuously pair - if someone wants to watch me work, or is too green to go it alone quite yet, its fine. But usually we only pair when it makes sense to, i.e. we are at the beginning of something and figuring out what to split up.
If management tried to force real continuous pairing down everyone's throat all the time....yeah no. That management should be fired, they don't understand how people work.
The 8h shift looking at a shared screen was absolute terror. No privacy, a lot of machismo with people claiming "I don't need to look at the documentation", terrible productivity when pairing with certain employees that didn't really took the work seriously.
Mandatory pairing simply doesn't work, period. It's like they say about therapy, wanting to do it is a pre-requisite for it working...
Yes. Especially ice chewers. Which one PM thought was hilarious as he worked through a cup of just ice.
Not particularly, but having to deal with distacting sounds, pressure to focus, and feeling trapped in a cubical can definitely make me uncomfortably anxious.
Not to be rude, but the stereotype of the software developer is fast becoming one of fragility. A low wage worker spending their day working a fryer or a guy at a construction site would be thrilled to have such working conditions to where their biggest problem is someone eating too closely while making $100k+ per year in the air conditioning.
Oh my! People complaining about things that are relative to the situation they are in! How fragile!
For some people, it’s quite literally perceived as someone’s kid screaming next to them.
What people forget is, we don’t have a choice. People who have a disability will have to deal with it no matter what job they do.
It’s like yelling at a person in a wheelchair to stop bitching about the lack of an elevator in a three-story office building because they have a “good job” and getting up the stairs isn’t a big deal because you do it every day.
This analogy may sound like an exaggeration, because there is no way you can comprehend something so minor and trivial could be a problem. And that’s kind of the point. It’s extremely difficult to understand something you haven’t experienced.
Most people jump to the conclusion that these things aren’t a big deal and they’ve seen people lie about it to manipulate people. Therefore, a person claiming to have a disability that isn’t obvious is lying to get things they don’t deserve.
Not everyone has a fully working brain or body. :(
Why is it so terrible for anyone to want to work in a specific environment that they find comfortable? Why do you think that the ability to work as a fryer or construction worker is somehow “better”? Why are people who have the capacity to either ignore or tolerate bad working conditions and continue working considered morally superior?
As human beings we’re all so different and unique in our ways and preferences. We are at a stage in our evolution where we can provide people the kind of environment that they prefer to work in; even let people choose the kind of body and gender they think works best for them. Why is that so bad? Can’t we just let go of the toxic masculinity involved in such comparisons?
I am not even touching on the nature of knowledge work itself which has very little to do with physical toughness and everything with being in environments conducive to problem solving. Please just stop with these rubbish admonishments.
Of course I'm happy to work in software rather than in fast food. And I think many people would prefer working a desk job rather than a physical job. But humans get used to things. I remember my time working in fast food, but it's hard to remember exactly how I felt and say "Wow, working in an office is way better" every time I encounter something that I don't like in an office. I also think that just because I have better working conditions now doesn't mean I should stop trying to improve them.
It’s a trained skill tho.
If you want me to explain code as I see it, I'll start in the middle of a function, where you have no context what it happening and jump to another line of code that is two functions removed. Repeat. You will have absolutely no idea what's going on as I flip through tab after tab of code.
My brain does not like doing things in order. I have to force it. Hence the processing overhead.
My friends find it entertaining to listen to me tell a story, because none of it is in order. I frequently backtrack or go down "irrelevant" paths, before returning to one of several previous threads.
Fortunately for this comment and the second and third novels I'm working on simultaneously, editing exists.
You seem to be explaining things from the point of view that your different way of thinking is a problem for others rather than an opportunity for them to grow and learn. That's kind of odd...
Personally I think it would be very interesting to work through code in that way, and I don't think it would particularly detract from my understanding.
If you'll indulge me, I'll try to explain using part of a story I wrote as an example. (It is a furry story, hence the animal body language.)
——
## My explanation
“You went grocery shopping?”
“About two hours from now.”
“You can relax,” he says after he sets the kettle down. His ears perk up, staring at me intently, and I steel myself. “I took the week off.”
“I didn’t expect you to be up so early.”
Then I notice the grocery bag on the table. Breakfast probably being oatmeal or toast; we were out of eggs.
“You okay?”
——
Who is speaking at each section of dialog?
1, 1, 2, 2, 1, 1
——
## Original
“Yeah,” he replies sheepishly. “You got three minutes to get dressed while I get your coffee.”
“You can relax,” I say after he sets the kettle down. His ears perk up, staring at me intently, and I steel myself. “I took the week off.”
He breathes out slowly, but his tail gets more frazzled. “And you were going to tell me this when?” he says with restraint.
“About two hours from now.” It’s my turn to look sheepish. “I didn’t expect you to be up so early.”
“Thought I’d make you breakfast.”
Breakfast probably being oatmeal or toast; we were out of eggs. Then I notice the grocery bag on the table.
“You went grocery shopping? Did you take your anxiety medication?”
——
Bonus round: What does “You okay?” from the previous section refer to?
There was a minor accident in the kitchen that let to this discussion.
——
This is a bit contrived and I mixed things up more than usual because understanding creative writing on paper is easier than explaining code over zoom.
There is a reason why nearly all good programming languages, standards, platforms and even games are usually started and prototyped by one developer. That is because programming is creative value creation and business/finance/project managers passionately want it to not be, they want it to be a factory and it never was, is or will be that until the initial versions are out. They want to value extract before the value creation, they also try their hardest to make sure no programmer has much power so they are "swappable" which again is not true in product creation, maybe maintenance or once the base is created, but not initially.
Programming is a creative skill and should always be seen that way. Most product developers, game developers and full stack to presentation developers know this and can make some of the best value creation because they can take it from start to finish. Once it is prototyped or first versions, it can be ramped up for value extraction.
This feels pretty relatable and sometimes also extends to code review, when another developer essentially goes: "Hmm, i don't like this for subjective reasons, you should rewrite it to be different." even in situations where doing so would have no tangible benefits and the only thing that ends up happening is the development velocity being ruined.
I think that sort of problem would manifest itself both in pair/mob programming, architecture discussions, sprint planning as well as code review, it's not like you can easily avoid it altogether, unless you avoid the people in question entirely or provide pushback against nitpicking and bikeshedding, which may or may not be viable.
That's why code review process must have a guidebook with a rule "it's on the reviewer to show why the suggested change has a tangible benefit".
Agreed, yet you're implying that:
- there must be a guidebook in the first place
- that it must actively be followed
It's unfortunate people are mostly conditioned to not oppose: whether to get branches landed faster, or simply because of the imposter syndrome, but some of us who are good at opposing and saying no sometimes struggle to find the right balance.
My goal when reviewing is to help others learn something new, which is why I'll sometimes share a personal, subjective preference for an approach (with "subjective" meaning that there are pros and cons to either approach with neither being better in every circumstance, especially in a legacy codebase like they all are).
I am trying to walk the fine line between teaching someone something potentially new, and not dumping on their velocity or self-confidence. I love it when people acknowledge the idea and say "nope", yet I understand that many won't do that, so most of the time, I stop myself from even sharing my subjective preference.
Outside of character, it requires building trust between people and not being out there to "prove your mettle", but to build stuff together. And with so much churn in jobs and remote work (I haven't met my new coworkers of 6 months yet, and I haven't met half the previous team either), that's sometimes hard.
When prototyping some new idea that might result in a new product/platform/module/whatever, I tend to iterate faster than I could explain my iterations to any other person, even well-versed developers, let alone average-skilled ones. It is normal to refactor the entire codebase multiple times a day in such situations. The internal reasoning processes that guide these iterations, the probability assessments followed by quick trials followed by another iteration that ultimately lead to a solution are so manifold and dealing with so many particulate details (that are of utmost importance however at such an early stage of a new system) that it is impossible and impractical to discuss all of them with someone. You just have to follow your intuition. Having two intuitions in play at this stage is counterproductive, the friction losses are just way too big.
This is literally the problem with interruptions and open-office floor plans for knowledge workers. There's no effing way we're all ADHD-addled goldfish. Decades ago my senior cube-mate liked to tell non-engineers who walked into our cube asking questions unannounced: "like I tell my wife, we're in here balancing a stack of plates in our heads, and you just walked in here and knocked them all down."
You're right about it being a house of cards, and the industry isn't doing us any favors selecting for people who can chat about it vs. arrange the metaphorical cards high and get the hard things done.
I struggle with this during technical interviews. I can't think deeply and explain what I'm doing at the same time. Since talking is required it means that I can't think.
The difference is the matter of degree.
I think you are mistaking in believing you have trouble explaining because you use a different thought process.
For almost everyone of us, figuring a complex system means you deconstruct the system in small pieces, understand the small pieces, construct the system again in your mind along with making a kind of mind diagram about how it works. But when it comes to explain to others you use a different process than you used to figure it out. You already have that mind diagram, so you proceed like in most text books or in articles by already providing the big picture and going in details only when you feel is needed.
I also write good code, but it doesn't have anything to do with attention or memory. You write good code because you believe it's important to have something that is working well and also will be readable and maintainable. And writing good code is something almost every programmer can do if the working environments permits - i.e. they are not valuing churning bad code fast over writing good, reliable code.
My genuine question - Is it possible to have ADHD and be a coder? It’s just that coding requires so much focussed attention over long periods. If you are enjoying a career as a coder I’m inclined to think either the ADHD is mild or treated very effectively? Or even that treated ADHD actually makes you better than the median somehow?
It has way bigger consequences outside of work for me. Things which you are very passionate about are easier to focus on than things you are not, regardless of AD(H)D.
A person with ADHD will have a tendency to get distracted from the task they're supposed to be working on, and will instead work on other things. That's not necessarily bad if those other tasks are important. Perhaps counter-intuitively, the lack of impulse control may even lead them to hyper-focus on a task... just maybe not the one they were assigned.
People without ADHD also get distracted, but they have the impulse control to better resist tempting distractions, and the memory to remember to return to their original task after unavoidable distractions.
My entire view of ADHD changed when I saw a video for parents of children with ADHD a few years back. This is one of my favourite HN comments of all time: https://news.ycombinator.com/item?id=17889156
Now, that said, there is a new movie, Everything Everywhere All At Once, and if you take this title as a stand in for ADHD, maybe you can see that while this way of living can be overwhelming it also allows you to have a pretty good overview over systems and how their components interacts very fast. I think that's what many ADHD'ers are actually very good at, grokking code bases or the gist of things very quickly. Systems thinking in general. Also quick recall / association chains...
Also, on average, the higher your IQ, the later in your life your ADHD diagnosis will be (see this video on adult ADHD https://www.youtube.com/watch?v=dVDhYtQkuO8). Your other abilities can compensate somewhat for your ADHD. Also of course when battling this condition you will build many personal tools and habits that neuro-typical people will never have to do, so in that sense you also might have a leg up in certain situations.
I'd say professionally the biggest problem is not so much on a technical level, but more on an emotional / impulse control level. ADHD'ers can come off as brash, speaking their mind freely, not being able to just put that comment in when it's better to shut up.
- Were you officially diagnosed with ADHD. I never went to a doctor, but in the last years I had growing assumptions I might have ADHD or Asperger (or both).
- Do you follow certain strategies which made communicating your thoughts and ideas easier and/or better?
Diagnosed bipolar 1 recently. But I was diagnosed as ADD as a child thirty years ago. ADHD is a popular addition to the standard Bipolar feature set.
> Do you follow certain strategies which made communicating your thoughts and ideas easier and/or better?
Not in a way I can easily teach. I learned my social skills late and had to study people to understand them. I take all of the inputs and outputs of a known person and mentally visualize what their internal state is. Then I play out how different phrasing will be received.
Whatever part of the brain normally handles social interaction is broken in mine, so I use logical thinking to run other people's brains in a virtual machine.
I guess I should get an official opinion. Nevertheless, diagnosed or not, virtualizing people seems like it could work for me, although it seems to take a significant amount of time for each person to work.
IF my dad IS talking about (politics|religion) THEN do not enter discussion.
> If this comment is a bit rambling, you know why. :)
Everyone has struggles with communicating clearly don't they? Do you think it is possible that we put too much emphasis on apparently typical and non-typical way of thinking, with one pathologised?
Would ADHD really be noticeable if we were living in a medieval agricultural society?
I'm speaking as part of a generation where boys grew up being medicated for what I saw over-diagnosis of ADHD.
Your confusion is very understandable because most people don't know what ADHD is. Some of the symptoms overlap with immaturity, so people who are not qualified to tell the difference will frequently misdiagnose the problem.
If you want to understand ADHD, this video for parents of ADHD children will explain. https://www.youtube.com/watch?v=YSfCdBBqNXY
You don't need to watch the entire 3 hours. The first 10 minutes should be fairly enlightening.
For the most challenging tasks, say, coming up with an original solution to an unsolved problem, I think it's better to alternate deep focused thinking alone with group brainstorming. But you really need that meditative alone time to gnaw at difficult problems -- for me it tends to be in the shower, or during a walk. That's where you have those awesome "Aha!" moments.
On the other end of the scale, certain mundane/repetitive/trivial tasks really don't warrant pair programming IMHO. You're spending two brains on something that really takes 1/4 of a brain.
The ideal case for pair programming, IMHO, are those tasks where you can visualize the general path forward, but where there are significant challenges wrt implementation such that another pair of eyes can really provide insight. For example, say you have to implement a module, and you have a general idea of what it needs to do, but the overall decomposition and abstractions involved may be inchoate. While I think a fair amount of "implement this new feature" type of stories fall into that category, in my experience that comprises only ~40-60% of the total workload.
The above mostly applies to pair programming with two fairly equivalent/experienced developers. I agree with others who have noted that it's a fantastic training mechanism for new/junior devs. And then, there are various special case scenarios that justify it, as in, you have a problem with X and need to pair with an expert in X to resolve it. IMHO, these are best done ad hoc rather than via a formal process.
However, solo thought doesn't necessarily activate all neural pathways that will solve problems.
Much like explaining problems to someone else often causes you to realize the bug, social interaction activates communication, idea formation, recall, association, and error checking neural pathways that don't necessarily fire when thinking in isolation.
So for 100% pair programming: again with the dogma in IT. 100% code coverage. TDD. Strict agile/process alignment.
Stop with the dogma.
For me, pair programming carries the implication that you're always doing it, which seems almost as bad as never doing it.
yes - lets talk frequently about the work and what makes sense
no - me watching you type and making off-the-cuff comments to keep myself busy
If we need to collaborate then let’s hit the whiteboard but please afterwards let’s work in peace on our own computers like civilized humans.
So is retaining engineers, so that, once they learn the system, are available to maintain/teach it, and more importantly, are invested in doing a good enough job, because they will have to be around to deal with the fallout, if it was not a good enough job.
There's no one answer, but I'd suggest that having an environment that retains engineering talent, and incentivizes good, long-lasting work, could be helpful.
Some downsides to pair programming I've noticed:
1) People can tend to jump to the first solution they find, in order to not look slow or stupid. This doesn't allow for time to refactor the solution.
2) It can promote a culture of "spoken-word documentation" where all information about the system is conveyed via word-of-mouth, and nothing is recorded. You can see how this isn't scalable...
3) Not everyone has perfect internet, desk setup, comfortable chair, microphone quality, monitor resolution, etc. and it can lead to one person mumbling and another just going "yup uh-huh yeah"
Right -- because they're not the ones actually doing the work of course. Aside form the typing "work".
A team with one expert and pairing is now a team full of experts.
Minus the ones who quit (or never joined) because they just can't get behind the insanity and teeth pulling that is (involuntary) PP.
Besides the domain and system knowledge sharing, besides exchanging productivity tricks or new ways to solve problems, it is much less distracting. I strongly believe that on any non-trivial task pair programming accomplishes much more business value (more tasks done) and growth than having the two developers working solo.
I don't think it should be the only way to work, definitely not most of the time and it should be encouraged rather than mandated.
I’m sorry, no. That’s not how that works.
Sounds like a plane crash. :)
> accountants will never understand this
Oh...I take it back then.
I'm an accountant. Apparently I didn't understand this, so I must have been mistaken in my above assessment.
Putting aside whether or not it actually makes you more productive, that sounds awful to me. Part of the reason I work from home is so that I don't have to constantly interact with my peers, and can put my head down and concentrate on my work without having my train of thought constantly broken. I have no problem with pair programming as needed, but I would never work at a company that forced it all day. To each their own, though.
Sounds like a nightmare. I interviewed once for a company where the team did exactly that, and it was the moment in the interviews I realized I don't want to work there.
ad-hoc peer programming is perfectly fine. Debugging something tricky or helping someone ramp up is great. But peer programming as-a-process is literally peer-micromanaging and outright insulting IMHO.
Some dude won the lottery / hit the bus. Minimal disruption to team.
Have ADD? Well your pair keeps you on task all day, so your biggest weakness is gone and your ADD brilliance shines through.
Need a few hours focus to figure out something complex. Ok this one wasn’t great.
However one of the most successful complex fault tolerant distributed systems projects I ever worked on was done in a team of myself and one other guy, delivered in about 9 months from start to finish, is still, as far as I’m aware, running flawlessly years later and was developed through 100% pair programming.
We did it be css use as a team of two it was important that both of us were intimately familiar with every line of code and understood every decision made, but it turned out to be an incredibly effective way of developing complex software.
Some things to note: you have to get on very well with the other person, or it’s going to be frustrating. You have to have similar standards and ideals or you will clash and fight. It’s an exhausting way to work and you will need to take regular breaks. You need to be strict about the roles and about swapping roles regularly. We did a lot of remote pair programming (voice call + screen share that allows input from both: we used screenhero when it was still a thing, VSCode has shared editor support nowadays that’s not bad, not sure what other tools there are)
Other people mentioned ADHD, I too have ADHD and this definitely isn’t my natural way of working. I even had some resistance to it most mornings and had to tell myself ok let’s go. And it IS exhausting, you need a lot of regular breaks, you need to be able to shut off and not think about work at all after hours or at weekends, it is a very tiring way to work.
But DAMN was it effective. I don’t think we could have delivered it in 9 months, let alone without known bugs, any other way. We would not have both had the same level of understanding of the entire system.
I mean, today I spent time:
- Digging into the analysts dashboards for some time series that seemed off. Generated a plot from my own metrics stash, filed a bug w/ the analysts about the differences. Replied to some doc comments saying that I'd done so.
- Code review of a few changes.
- Write a quick jupyter notebook (well, colab) analyzing a different problem. Basically reading the data for an example into the notebook, writing a bit of code to visualize it, fiddle until I had some sense of what the problem was.
- Decide I should regenerate a dataset with some different processing. Spent maybe an hour doing the code changes and getting them reviewed. Then build the binary, run it to generate a dataset, then launch a few-hour processing job to see if it works better.
- Write some notes on how I should decide if the new version is better than the old version.
- Fire off email to a few people. Asked one person about existing viz tools, updated another about my earlier colab experiments and asking if they know of anyone who's done a similar analysis.
Out of all this, I think pair programming would have maybe been tolerable for a bit in the middle when I was actually making code changes, but everything else was either based on huge amounts of internal context or was completely ephemeral analysis.
I think I must be doing a different kind of thing. :-)
Some of them advocate for 100% "mob programming" (3+ people working together).
Doing it on a "as needed" basis is common sense and doesn't need a buzzword name either. It's what people have always been doing. But to push for 100% of it is insane and insulting to the individual.
On the "mentor" side of such pair programming, it is extremely useful to have to verbalize things that you may have gotten away with only fuzzy knowledge of previously. When the new hire asks a question that makes you say "oh wow that actually is quite broken!", you win as well!
This should happen anyway - pairing or no. What kind of onboarding are people doing where architecture overview isn’t a part of it?
NOTE: this next part applies to the US.
Why? Developer salaries went vertical when COVID hit. All those Silicon Valley jobs became remote with big fat salaries and companies took months to respond, and many did not respond at all. The job I started last year I would have left if it weren't for the fact that I work well under 40 hours for a 6-figure salary.
If you are getting paid less than 100k/year with at least 3 years of experience, find a new job. Don't treat your job like it is your life. It isn't. They would fire you if they knew they could have someone do your work for half the cost, so don't let them "use you against you".
Would using an improved Github Copilot be similar to pair programming but without the stress?
Let's assume Copilot can understand whole projects not just single files, can do proper dialogue, is able to generate test cases and explain code.
Pair programming is fine in learning but the team of uniform level experts is too much of a fairytale idea to me for a generally useful concept in the complexity of life (and projects). Don't blame the pointed-haired bosses and accountants alone if the variety of workforce and projects, life itself (differences, variations, uncertainties, logistics, economics, ...), speak against the precious pair programming here and there and it will never be a 100% soluion for everyone and everything. Except if you eliminate/refuse situations with opposing aspects rigorously and without mercy of course.
I recently learned that some database system, internally, always performs two operations in the specific consecutive order. It was quite critical for my task at hand and no-one on the team was able to answer this precise question about the order, including team leader with deep historic knowledge. I had to read code, I had to prove that this sequence will be exactly as I need in cases that are important for me. And I read and reread the code before that "proof process" even to get the understanding that I can implement my solution if I can guarantee that order somehow.
"All easy problems are already solved", if I may quote fortune program.
The hard problems take time for research. By doing that research yourself, you learn how to do research, you learn code better and, finally, you are not doing research with someone who, well, may not know solution for your problem and may not even have a clue on what may help you with the solution.
The last point means that you are not wasting someone's time and you are not wasting your time too.
You say "A team with one expert and pairing is now a team full of experts" and I cannot agree with that for any problem domain that requires any kind of research.
Personally I can think of few things more exhausting and detrimental to my wellbeing than suffering through pair programming.
You can get most of the benefits just fine without it, with occasional sessions, without the cost of driving away people.
I paired with a young woman fresh out of a boot camp, and at first I was excited to do it because it was nice to have another woman developer. Yet she was just so threatened by me or insecure about her experience, she started gossip about me. Just awful
Another time it was with a mid level middle aged man, he just had a huge ego and felt the need to question single thing I did.
Honestly the best pair programming experience I had was with a "sports bro" type. I always wonder if it was due to fact coaches are a big deal in sports.
I refuse to do pair programming these days if I can avoid it.
He argues that the biggest determinant on whether maintainers on a system they did not build will succeed is whether they will have access to the original developers: "The conclusion seems inescapable that at least with certain kinds of large programs, the continued adaptation, modification, and correction of errors in them, is essentially dependent on a certain kind of knowledge possessed by a certain group of programmers who are closely and continuously connected with them."
"mathematical understanding does not expand in a monotone direction. Our understanding frequently deteriorates as well. There are several obvious mechanisms of decay. The experts in a subject retire and die, or simply move on to other subjects and forget. Mathematics is commonly explained and recorded in symbolic and concrete forms that are easy to communicate, rather than in conceptual forms that are easy to understand once communicated. Translation in the direction conceptual -> concrete and symbolic is much easier than translation in the reverse direction, and symbolic forms often replaces the conceptual forms of understanding. And mathematical conventions and taken-for-granted knowledge change, so older texts may become hard to understand.
In short, mathematics only exists in a living community of mathematicians that spreads understanding and breaths life into ideas both old and new."
https://mathoverflow.net/questions/43690/whats-a-mathematici...
Mathematics is by far the biggest and longest running open source project on this planet and we are absolutely able to traverse it by centuries or millenia. This works across languages and cultures.
Mathematics is built on a small set of axioms and everything else is defined on top of it and proved.
Your comment makes it sound like there is some magic knowledge linked to arcane symbols, when mathematicians are the least interested in symbols and labels, they care about definitions.
As with any field if you get in highly specific topics then obviously you are going to lack enough literature and tradition on these topics and something may get lost, but if everyone forgot all they knew about math today we would be easily able to get back to where we are in a just by reading.
If your definition of "easily" is the amount of work required to become a mathematician, then sure.
Not only this is far from a general truth, we all maintained codebases we knew nothing about I guess, but it applies even less to mathematics, which is a language based on definitions built on few concepts rather than vague and buggy business requirements.
I recognize that this is due to my imperfect summary/introduction of the paper, but it doesn't make that assertion. I highly recommend reading it; it's not that difficult or technical.
I've maintained systems where I could talk to the original developers, and I've maintained systems where I couldn't. I know there's a difference in outcomes between the two cases, but I wouldn't say the latter is "not maintainable". Certainly buggier and slower to develop against, though.
Afterall, this is what happened to a lot of famous mathematicians. Their texts were forgotten, and then rediscovered a very long time later, and sometimes proofs could not be recovered for a long time (cf Fermat)
This goes against what I understand about mathematics. I've tried to break it into a few sections.
Open source:
Things in mathematics once defined, tend not to change, even when changing would be beneficial.
Open source software tends to be a bit more malleable, but even long running things that can't change for fear of breaking things like POSIX or the X Window System end up getting alternatives that the industry slowly turns towards.
But mathematics just stays stuck. Multiple subfields will end up using the same glyph to mean two different things and when those subfields intersect it gets very bad very fast.
Even small quality-of-life fixes never end up getting accepted into use.
Here's a great example by 3Blue1Brown: https://www.youtube.com/watch?v=sULa9Lc4pck
Another example (if you're interested in going down a bit of a rabbit hole) is the history of vector algebra vs quarternions. We ended up going with vector algebra, then learned that quarternions were actually better, but we continued to teach / and be taught vector algebra.
> we are absolutely able to traverse it by centuries or millenia
Well, this seems easy to disprove since knowledge does get lost and things keep getting rediscovered.
For example, Calculus was rediscovered multiple times: - Archimedes (at least part of it with his method of exhaustion) - Leibnitz / Newton (separately) - and recently: medical doctors rediscovering integration and publishing papers on it in the 90s.
Other famouse examples would be Fast Fourier Transform, and perhaps Fermat's Last Theorem
Wait, what?
I'm still mostly familiar with assessments like "Quaternions... have been an unmixed evil to those who have touched them in any way" and "quaternions appear to exude an air of nineteenth century decay" (but not actually familiar with quaternions beyond a vague understanding of them as kind of 4d version of complex numbers).
Can you provide an example?
Mathematics definitely change as soon as someone provides a proof that something isn't correct.
Consider the 'standard' definition of the complex numbers, whilst we know there are more intuitive options.
Consider tau vs pi. And how hard it is for anyone to write mathematics based on tau.
Consider the rather lacking notation for probability with conditionals.
That is a profound conclusion to reach. For the most part, I think it's true.
Without someone who wrote/fully understands source code, for example in abandoned software, the source code is a treasure map, the as-built plan of a building. It takes a lot of time and effort to orient yourself with things and make reasonable guesses as to what is going on. This aligns well with the original post.
Like, if they come with a change request we might ask what about X, they'll get all surprised saying no we don't do X, but after a bit of prodding sure enough, they discover they have a worker that's handling X every day.
This is simply because we've been around, while they've had multiple new persons cycle through their departments. When they change the ERP system, we've still got the guy who coded the integrations with their previous system.
But hey, that's just me. And it seems clear that most businesses do a poor job, or don't care at all, when it comes to documenting their processes. So I guess I'm the odd one.
I remember once in a consultancy job for a bank having to maintain a form with a file uploader made of dozens and dozens redux actions interwhining in the most complex way one could imagine. There were atleast 4 folders of sagas.
No one could understand the code, I fought it a few days before deciding to manually document its cases by trying all input combinations I could think of and just rewrote it fromscratch in less than 250 locs. Took me an afternoon to rewrite it and do the maintenance task.
If I had e2es since the beginning I could've figured it out sooner..
1. For one, I think it's hard enough just to keep technical documentation up to date. Keeping separate business process docs up to date with code feels like it would be a collosal task.
2. That said, most software at least starts with some amount of requirements (whether that be a formal spec or a bunch of Jira epics). I have rarely seen any engineer start first by reading all of the old business requirements before trying to understand the code.
3. Even if the business requirements were documented perfectly, I rarely find that they are the major issue with understanding a code base.
If the business doesn't know their process well enough to document or explain it, don't you think there will be water effort and rework, especially for edge cases?
I've found that for most systems, there are three great ways to "figure it out".
* Start from input. (Browser, API, whatever starts a process.) Map from there.
* Start from data storage. (Database, flat files, whatever.) How does state get persisted?
* How does the system move into production? If you can make a small change (even adding an innocuous comment) and see it all the way from your machine to prod, you can iterate and start to map the system.
* Data storage: what does the schema look like? Even if it is not persisted to a relational DB, is it possible to draw out a schema of a data model and all the relationships ("JOINS")
* Add logging to code you are trying to debug but are hard to understand and repro bugs for in production. Once you have logs about the full state that reproduces the error, the issue will be easier to fix. Don't roll out a fix before fully understanding an issue. As a corollary to this: always add a task to remove this verbose logging you added once the bug is fixed!
This is a great idea and should absolutely be a standard. There's a whole logging level ("DEBUG") devoted to this that I think goes way underused.
Another, related idea is to use a debugger. Using PDB for Python codebases has sped me up A LOT.
The ability to switch to DEBUG level, get a wall of text from a problematic spot, and switch it back to WARN was very, very helpful for troubleshooting prod.
Reminds me of Fred Brooks' famous "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious." quote
I have gotten quite a few comments from former co-workers who have taken over some of the projects I was lead on about how easy it was to read. That brings me a lot of joy, knowing that I made their lives easier and that the output of the trade I invest so much time and energy into is appreciated by my peers.
That said, I think `self-documenting code` is the bare minimum in 2022.
At my current role, I'm pushing the org to become "documentation first"--but this goes way outside the scope of writing code.
It's about writing all 4 types of documentation[] as a daily practice. This way, when you create something or learn something, that gets documented for the next person. It's not just about what variables and functions are for.
It's about what the business is doing and how that relates to our work, what our poor backend-cum-devops folks are having to do day in and day out, and about helping everyone accomplish their tasks without needing to go around getting help from 3 different people over 5 days because the system is completely opaque.
The big drawback (right now?) is that diffs are computed on a line basis rather than a semantic token basis, so a bug fix for a comparison operator obfuscates the raison d'être of a whole conditional.
// function to get the recipes
function getRecipes() { ... }
Where have you heard that writing useful comments (e.g. explaining an edge case, explaining a technical workaround, etc) is a bad practice?
// function to get the recipes (!)
function getRecipes()
For example: http://web.archive.org/web/20100415205750/http://blog.weapon...
They are pretty clear about "useful comments" - by what they wrote, it sounds like they already understand what you wrote.
But there is also information that you can't just describe into the code. There are the examples I already gave above. Another one could be what I did this afternoon: I had 2 options to solve a problem, I chose the more complicated one but the one that works in every case. I added a 4 lines comment describing the second option and why I didn't use it. There is no other way to add this information that would be useful for me or another developer in the future other than a comment.
At least once I forgot to add a comment in such a case and luckily I got the question of "why not just..." in the code review.
No-comment self-documenting code is largely a backlash to this style, which is how introductory coding courses teach (taught?) was the right way to do comments. For a lot of programmers who first started in in one of these courses it tended to stick because they were never taught another way.
Maybe? Not sure - haven't worked on enough big projects to declare answer
>A new developer is supposed to go through all the codebases and figure out for himself?
Yes to this bit - code should have very clear structure to it with appropriate comments attached, whether that's literate style as JonesForth<https://github.com/phf/forth/blob/master/x86/jonesforth.S> shows, small section header comment or whatever.
It should be very clear what section exploring does - tiny example but cat<http://9p.io/sources/plan9/sys/src/cmd/cat.c> from plan 9 very simple segmented code - deals with file opening in main loop and cat function just reads and prints text
If your code is sufficiently clear there will be nothing left to say in the comments, the comments will have to repeat what the code is already telling you which significantly diminishes the value of comments.
>You don't write README.md
I don't think people are talking about self promoting projects or self documenting projects.
>ARCHITECTURE.md
or self documenting architecture.
>JavaDocs, etc, at all?
or self documenting libraries.
Seriously, what's so hard to understand about looking at code and then understanding it because you read it instead of having to read comments to understand the code that is in front of you? You seem to be under the wrong impression that self documenting code is a negative process where things are taken away rather than added.
And unless your programs are formally verified this process that you have codified most likely will not meet the requirements to satisfy the intended purpose.
A typical non-technical "assignment" that's given before someone is fluent is to describe in excruciating detail/list of steps how to make a peanut butter and jelly sandwich. The point of the exercise is to show students that you need to remove all ambiguity. Or at least as much as possibly. What the exercise doesn't show is.. why are we making a list of steps to tell someone how to make a sandwich.
“If you give me six lines written by the hand of the best debugging programmers, I will find something in them which will hang his operating system.”
Incorrect. The code can never tell you WHY. That's what comments are for.
I used to be a big fan of doco and still am. But a founder once told me that it is better to have intuitive UX (which obviates the need for documentation) and that rang true.
Remember reading this <https://raspi.tv/2015/documentation-and-commenting-your-code> article on importance of comments
Even the piechart labeled "True effort required for many large-scale systems" says 7% of "effort" is Integration Test, and 8% in Module testing...
Want to raise my hackles? Give me statements with lots of precision but lacking in documented (not to mention repeatable, reliable, or robust) accuracy.
Convolved on this numeric silliness are several cartoons of smiling faces with vapid captions like "The figuring out time is a decision making time" or "Assessment is the process of understanding a situation around a system enough to make a decision".
The rest of the short article builds an arguments based on the assumption that at least 50% of the development time is spent figuring the system out. If you find this assumption to be off base, please disregard the rest of it.
In any case, I'd encourage you to ask peer developers if they find that they spend 50% or more of their time reading textual artifacts as a way to figure the system out (code, logs etc).
Maybe one slight variation, that I think still agrees in principle, is considering 'the cost of doing this now vs cost of doing it later'.
Sometimes technical debt is isolated and handling it can wait until the next time that code is touched. Often people may use this as an excuse.
But there are a few cases where you can just wait and it won't be harder to fix later. I suppose this is the real form of debt that people should be referring to when they typically think of technical debt. It's debt with a next to zero percent interest rate. Just borrowing a bit of time now from future engineering time.
A lot of technical debt that is left is the kind that carries a few thousand percent interest rates and can quickly tie an organisation in knots.
We start teaching about software like it's 'algorithms' when that is frankly, almost pedantic. That was never the hard part.
Scaling the complexity was always the hard part.
Simple, clear code, absent leaky abstractions, enough documentation etc..
Software engineering is extremely difficult
And it's not 'hard for most people' it's hard for everyone.
Every API is leaky and inconsistent, it's all a matter of degrees.
Concise documentation is essential. I'm reading about a Java API for the 5th time and only now just 'getting it' fairy clearly, it's not rocket science it just needs to be explained properly. Java 'Direct Memory Byte Buffers'. Simple concept, described poorly!
* Coaching/Mentoring - Original developers there to help
* Great documentation - App is documented, and it's easy to discover how it's put together
* Great API / abstraction - The api or structure is really easy to understand and use - this is why REST beat out more sophisticated API models. Even so, it needs great documentation to be easy to learn and build with
I think a lot of companies don't get any one of the three above right, so everything is very opaque. Also, you can't let tooling block developers from getting into understanding the code. New dev onboard times are a great way to measure this.
I wish I could transmit this concept in my organization.
1) E2E tests as business requirements living documentation are the best first step any organization/project can make besides their tremendous technical value. At least remove the need from contributors to figure out business from code.
2) Confluence-like services cannot work as technical documentation. There's plenty of tools that allow you to generate docs from code, use them!
We should lessen the friction from abstract to development,and that starts with providing good tools that bridge tge two.
This is one of the areas we actively explored and validated against. For example, take a look at: https://vimeo.com/498735070
This is one area where microservices can be a PITA if the dev environment hasn't had the same attention paid to it that the production environment has.
It's a lot like setting a minimum code coverage rule like 80 or 90%, people end up cursing the rule as it makes them do stupid things to satisfy the rule. Code coverage is one great tool to explore where your code needs more tests, but it's not the only one, and it's not the point. The point is writing code that's easily maintained, safely changed, and can be delivered to meet customer needs.
You hired really smart people (hopefully) and you should let them decide how to work.
Would love to see more web frameworks adopt this opinionated methodology to save us all some time.
And I say this as someone who originally live-edited PHP sites over FTP on apache in the early 00s. Convention is everything.
Rails can be quite a disaster, but it has some solid conventions on app structure, routing, and security. It's not that Rails is great, it's that having conventions and sane defaults that get you somewhere instead of nowhere is better than not having them. No other major popular framework that I'm aware of has any real conventions on app structure or on any of the core things that 99% of apps need anyway, so everyone is out there re-inventing the wheel.
In most frameworks, you get almost nothing included by default, and have to make key decisions on things like how will you encrypt cookies, how will you do CSRF protection, and sometimes even more basic things like how will you do routing. This has led to rampant security vulnerabilities reminiscent of the PHP days of yore imo. Productivity-wise this has made it impossible to get anything done, because the second you go to work for a new company, you end up having to help them re-implement basic processes like integration testing, CI, app structure, because everyone in the wild is just flying by the seat of their pants and making it up based on their limited experience and knowledge. "Oh, we just copy paste this boiler-plate and manually load SQL files for our migration system" "What's CSRF?" "What do you mean having separate environments for development, testing, staging, and production?" "Oh, we kept getting that CORS error so we just added a wildcard and it went away" etc etc
The early days of Lighthouse IDE seemed to veer a bit into this by they since diverged.
I find the best was to make your code grokable, is to have junit tests for everything that run fast in the ide. When code needs maintenance, you can run it in the debugger quickly and see what it actually does, instead of what it was intended to do.
The worst Java code is lombok code that gets fsked by aop and/or hibernate. I call these abominations Nojos (not plain old java objects)
Again: burn lombok with fire. Wrong line numbers, ungreppable code, obsure bugs, different depending on the lombok version 70% maintenance cost compared against, two seconds to have your ide automatically make explicit the code you are going to run.
I think there is a clash of concepts. It took me a lot of time getting used to the smalltalk workflow of experimenting in the playground and jumping into the editor to change things.
It is very different from recompiling and restarting or from running a repl.
It can also be extremely specific "I want to split a ReadOnlySpan<char> on some delimiter (which you can't do, you need to cast to a string and use the Split method there). Fortunately, that was an easy thing to find an answer for.
Sometimes I want something specific that I have no clue how I would even start looking for the answer. I want to build a web app with a modular payment end-point so I can plug/play a large number of providers (ideally, I'd be able to arbitrarily hook in Stripe or the Bitcoin Lightning network or something else entirely). There are a host of problems for me here; I don't understand the problem space, so I have no clue what a "good" solution would look like, I don't even know if generic payment APIs even exist (zero research on my part), let alone in languages I understand (go, python, C#).
I guess my issue is formulating questions appropriately, so that the sum of answers is an answer to my driving question "how do I do X?"
People who have knowledge-worker jobs and are halfway decent at them spend a lot of their time planning and making sense out of the systems they work in.
Believe it or not, the oft-derided-on-HN MBAs and marketing people figure things out, too!
Consider how the marketing work changed over the past decade to integrate data science. The amount of time spent on decision making might have not changed, but how the time is spent did change significantly.
The article argues that the same thing should happen in software: developers should spend less time gathering information through data science and more time making decisions. This happens to change the nature of programming.
The tool is (from what little I could glean) supposed to make discoverability better. That suggests to me that they know something about how to make things discoverable, by bubbling up important information, hinting at where you want to go. The website was pretty much NOT that. Sure, maybe it's one of those "the shoemaker has the worst shoes" things. I'm interested, but not interested enough to work hard at figuring out what the thing is even supposed to to. If I want to work hard to explore the inside of a system, I can already do that.
For example, I couldn't find docs on its display stack, so when I wanted to display a graph but with images instead of text for the nodes, I got stuck. Sure, I could dive into the code and eventually get something that worked, but I wouldn't be sure I was coding to the API or to the implementation. It crossed over to "playing around with this tool" to "have to do some real work to understand", so I ended up dropping it.
To this end, there are custom little tools inside (some ~2k of them) that help you in this exploration. For example, one of the first things we encourage people to learn when they start with GT is how to query the GT code from within GT.
Indeed, we are still to improve the onboarding experience. To this end, more recently, we added a book with live explanations. This is still a work in progress.
That said, GT should be approached as a language. One can do as much with basic hello world exercises, but to extract more value one has to go into deeper details.
Of course this doesn't work for projects utilizing brand-new technology but it doesn't make sense to throw all types of projects into one pot. If there's a case to be made that mature code bases require less "figuring out time" then organizations should discourage jumping on the latest technology "just because".
You mention a 3-6 months. That's quite a high price. Would it be inconceivable to optimize this significantly?
Stability can also be misleading. It's especially the small changes that can be problematic because when the code is large enough, people simply do not know what of what they already know (what's already in their memory) is no longer true. This is the challenge. Instead, the proposition is that we should not have to rely on our memory of things that can change. We can just check it. Only to do it in a reasonable timeframe, we need custom automation.
In any case, the article does not propose a tool. It proposes a way of working. The tool is important to show how it can work in practice.
The doubtfulness of that axiom is why writing code that is easy to read and understand without special tools is so important.
If they (management) choose to ignore our guidance, or straddle us with bad tools, it sucks for us, and them, and the company.
Too many maniacs in this industry.
Read article about how great these tools and libs are, how "easy", how they save so much time. Thinking about what i am doing wrong. Illusion. Self-deception.
Try 1000 other libs and tools and frameworks and and and, repeat in an endless loop.
My real productiv code is absolutly tiny compared to the huge amount of work i have and how much a permanently learn and educate myself.
And I'm utterly flabbergasted how many developers don't understand this.
Has anybody tried it?
Nice triple negation there...
I've thought about this problem for a long time. The conclusion I've come to is that it happens because the code doesn't look like the domain. Domain language is often missing in the code the engineers are working with so when new changes are requested the engineer needs to translate between the domain language and the language the code is using. I work in an object oriented language so my perspective is as follows:
Ideally, all that should be required is a correct domain understanding. If the objects in the code reflect the domain as understood and explained by the people giving the requirements then the engineer's job becomes easier. Instead of solving 2 problems, translation and engineering, they only need to focus on engineering.
For example, imagine a payment system. A requirement comes in stating that the way a credit transaction in a payment is processed has changed. The transaction should now be processed by doing x, y, and z instead of a, b, and c. The engineer should be able to find an object in the code called a payment that has a credit transaction object with a method named process. Once they find this with a simple text search they know exactly where their change needs to happen. They should then see a, b, and c happening as explained in the domain language. Once this is identified the change can be performed.
In reality, we seldom find domain objects with domain behavior in our code. What we find are Processor and Controller and Handler classes that have nothing to do with the domain. The behavior or data that we need to change is spread among multiple of these classes whose connection was arbitrarily decided by another engineer at a previous point. The new engineer has to work twice as hard to understand what decisions the previous engineer made to represent the domain.
It's much easier at first to do this translation work because we don't want to, or have time to, understand the domain. But business domain experts are experts for a reason. They know how to solve business problems within their domain. We are not domain experts. So we end up reinventing the domain solution wheel when we do things this way. We end up solving the business problems and the engineering problems.
Instead, we should see ourselves as modelers. Remember that computer science arose as a sub field of physics. The main purpose of physics is to develop models that represent the real world and solve problems using those models. Our job as software engineers is to model the domain and solve problems using those models. Our job is not to translate requirements into technical solutions. Nor is it to solve business problems.
However, we can still do much more than that. Take your example of searching textually for a class / method. First, when we search by text we assume that code has no structure. Would it not be a significant optimization to have a search that allows you to be search semantically through your system?
Now, the problem is that a system is interesting from many different perspectives. - For example, a security issue is most likely going to be crosscutting the domain. When we look for it, we would like to see a projection of the system specifically for our problem. - Or take communicating with the domain specialists. Most often, that communication happens on the whiteboard. However, what is manually drawn on the whiteboard represents what the writer thinks, not necessarily what the system is. To see the system, we should want the system to draw itself on the whiteboard. Any manual intervention in this process introduces an interpretation that hinders the communication. So, we can start with writing on the whiteboard when the system does not exist, but as soon as it does exist, we should have the system draw its representation. That can enhance communication manyfold.
it's not worth the effort to completely automate something that one has to perform maybe only once in six months or once per year.
This argument is patently flawed and wrong, because it assumes that it's only worth automating something if it is done often enough. Scientifically, "often enough" isn't quantifiable, and that argument completely neglects the repeatability aspect: by fully automating, the steps to perform something are codified and quantified.