No post body was provided.
Developers spend most of their time figuring the system out
21–30 of 418 posts
Re: Developers spend most of their time figuring the system out
#22I’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 future. There is so much room for innovation regarding ways to extend and augment the text formats used to author and represent software systems.
Re: Developers spend most of their time figuring the system out
#23People 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…
You don't think this depends at all on the particulars of the developer(s)? E.g. their personalities, experience, skill level?
Re: Developers spend most of their time figuring the system out
#24As someone trying to learn spring boot and lombak to write a complicated service... yeah, this. But I'm not just reading my code, I'm reading abstractions piled on abstractions. It's crazy. In the end I'll have to write less code, but I have to understand so much more just to write that "less code".
Re: Developers spend most of their time figuring the system out
#25People 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…
You don't think this depends at all on the particulars of the developer(s)? E.g. their personalities, experience, skill level?
It seems counterproductive to have developers on your team who aren't capable of collaborating in this way.
Re: Developers spend most of their time figuring the system out
#26People 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…
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 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.
Re: Developers spend most of their time figuring the system out
#27Relevant to this article is Peter Naur's paper on Programming as Theory building: https://pages.cs.wisc.edu/~remzi/Naur.pdf 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…
That paper is amazing. Completely changed my view on programming. For those who find it a bit inaccessible (as I did on my first read), I wrote an article about it a while back, explaining it further and giving real-life examples:
Re: Developers spend most of their time figuring the system out
#28I spend about 60% of my non-meeting time fighting with broken tooling that was supposed to make my life easier.
Let me guess, 60% of this time fighting with broken tooling is in-house tooling. But I feel you. You are not alone.
Re: Developers spend most of their time figuring the system out
#29Earlier 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?
It seems counterproductive to have developers on your team who aren't capable of collaborating in this way.
There's a chasm between "developer who always pair-programs all the time" and "developer who isn't capable of pair-programming".
Re: Developers spend most of their time figuring the system out
#30People 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…
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.