> we should start by talking about how not to read code. We cannot afford not to.
Nice triple negation there...
Developers spend most of their time figuring the system out
51–60 of 418 posts
Re: Developers spend most of their time figuring the system out
#52Earlier quoted context omitted.
That just can't be more productive over the long term, though. 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 incredibl…
There are other benefits, pair programming reduces a whole category of simple bugs/typos to basically 0, keeps people on task, offers (literally) immediate feedback. 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…
I agree with the benefits
But you also have 2 developers using 100% "of their cpu" during that time, which is really unsustainable for longer periods.
Re: Developers spend most of their time figuring the system out
#53Earlier quoted context omitted.
You don't think this depends at all on the particulars of the developer(s)? E.g. their personalities, experience, skill level?
The studies I've seen about pairing show that it's OK for beginners or lower-skill developers, but absolutely less productive for expert/senior developers. So yes, you're correct.
Forgive my possible laziness in searching, but do you by chance have links to some of the studies you reference?
Re: Developers spend most of their time figuring the system out
#54I’ve always been fascinated by the glamorous toolkit project. Their ambitions are fascinating and align closely with software I’ve daydreamed about on more than one occasion. I wish I was more comfortable with lisp, or that it was compatible with Svelte/Typescript/Deno/Tauri which account for 90% of the projects I work on. I hope projects like this and Enso[0] are early iterations of what IDEs will look like in the f…
Thank you for pointing me to Enso. This looks amazing. For the others, here’s a video demo: https://youtu.be/fQvWMoOjmQk
Re: Developers spend most of their time figuring the system out
#55People always struggle or avoid doing pair programming, and people always think it means that the developers' time now costs twice as much, but this is a total lie. When I worked at a place that did 100% pair programming with rotation every day, a new developer could hit the ground flying . Sitting next to someone who knows the system and can answer your question immediately means you get up to speed millions of time…
If you worked at a place that did 100% pair programming, anyone who couldn’t succeed at pair programming would be filtered out.
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. :)
Re: Developers spend most of their time figuring the system out
#56This seems like a really, really good justification for the Rails Way of having a sane and predictable app file structure and layout where developers who have never seen your code before can jump in on day one and figure things out very quickly.
Would love to see more web frameworks adopt this opinionated methodology to save us all some time.
Re: Developers spend most of their time figuring the system out
#57Question though: what about very stable codebases that are actively developed for a long time. My team maintains a couple SW projects (for internal manufacturing and equipment automation) with a core that has been stable for 10+ years. Once a developer is up to speed (3-6 months) that cost is recouped over several years.
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".
Re: Developers spend most of their time figuring the system out
#58I get the impression that there are many professional developers who have never actually seen good documentation at any point in their lives. So many organizations think that having all of the functions listed in on a Javadoc page is somehow the same thing as documentation. And they wonder why it takes a new developer months to become productive..
And then you have the common argument that comments are bad practice. If I can read 2 lines of comments for every 20 lines of code while navigating a large codebase until I find the code I really need to dive into, the productivity gains from that are nothing to scoff at.
Writing self documenting code alongside comments makes things so easy on people who have to understand your code later on.
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.
Re: Developers spend most of their time figuring the system out
#59Earlier quoted context omitted.
That just can't be more productive over the long term, though. 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 incredibl…
There are other benefits, pair programming reduces a whole category of simple bugs/typos to basically 0, keeps people on task, offers (literally) immediate feedback. 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…
Can you provide this evidence?
Re: Developers spend most of their time figuring the system out
#60Earlier quoted context omitted.
That just can't be more productive over the long term, though. 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 incredibl…
There are other benefits, pair programming reduces a whole category of simple bugs/typos to basically 0, keeps people on task, offers (literally) immediate feedback. 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…
I don't mind pair programming but I don't have the physical/mental capacity to do it for a full work day. I can only imagine how exhausted I'd get after several weeks of it.
When I do pair, I only work for 3 or 4 hours that day total.