Developers spend most of their time figuring the system out • Hacker News Board

Re: Developers spend most of their time figuring the system out

#191

Post by Supermancho » Thu, Mar 31, 2022, 1:04 AM UTC

WindyCityBrew wrote: post #39

SomeCallMeTim wrote: post #26

Earlier 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…

> 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.

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.

Re: Developers spend most of their time figuring the system out

#192

Post by treeman79 » Thu, Mar 31, 2022, 1:09 AM UTC

gleenn wrote: post #19

People 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…

Going on vacation was awesome. Only model I didn’t worry about anything.

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.

Re: Developers spend most of their time figuring the system out

#193

Post by usefulcat » Thu, Mar 31, 2022, 1:09 AM UTC

GnomeSaiyan wrote: post #179

CliffStoll wrote: post #138

Wow - is nobody else bothered by all the empty precision? 57.62% Comprehension, 23.96% Navigation... 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 n…

Can you explain like I'm 5? I'll be honest I have no idea what you're even trying to say here.

It’s a red flag when you see very precise numbers for things that are inherently difficult to measure.

Re: Developers spend most of their time figuring the system out

#194

Post by mjrbrennan » Thu, Mar 31, 2022, 1:11 AM UTC

toomanydoubts wrote: post #100

kayodelycaon wrote: post #55

Earlier quoted context omitted.

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…

Thanks for posting this. Yesterday I came across a job position on a company that does 100% mob(!) programming everyday¹. This means every programmer works 6 hours per day on a zoom call with 2 other programmers, rotating roles between typist, navigator and support every ten minutes. 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,…

Doing this in person sounds bad, doing this over Zoom would be monstrous. Back at a previous job I had to do pairing for many hours of the day over Zoom with less experienced developers, and it was unpleasant to say the least!

Re: Developers spend most of their time figuring the system out

#195

Post by rajin444 » Thu, Mar 31, 2022, 1:20 AM UTC

Jensson wrote: post #157

bdamm wrote: post #112

Earlier quoted context omitted.

Good design and getting everything right up works right up until the requirements change and the design no longer meets the ask. Unsurprisingly, teams might not even know all the requirements when building something new. Having everything orderly up front is a pipe dream. 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…

Good design can handle changing requirements, otherwise it isn't good design. Good design requires a lot of domain expertise and not just being a good programmer since you have to be aware of what kinds of things the system should be able to handle, but it isn't impossible. 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 ye…

> Good design can handle changing requirements, otherwise it isn't good design

Only if changing requirements are a requirement :)

Re: Developers spend most of their time figuring the system out

#196

Post by selectronics » Thu, Mar 31, 2022, 1:27 AM UTC

mooreds wrote: post #5

Haha, so true! 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…

Chiming in that this applies to controls engineering as well (think PLCs). Start from the IO, cross-reference that through the rest to get a feel of chains of causality and how it all works. Oftentimes it's critical to go from zero to applying changes as quickly as possible when unfamiliar (and poorly documented!) machinery is down.

Re: Developers spend most of their time figuring the system out

#197

Post by dkersten » Thu, Mar 31, 2022, 1:28 AM UTC

gleenn wrote: post #19

People 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…

I’m the type of programmer who likes to shut themselves away from the works in silence while I work.

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.

Re: Developers spend most of their time figuring the system out

#198

Post by briandear » Thu, Mar 31, 2022, 1:30 AM UTC

brailsafe wrote: post #109

kayodelycaon wrote: post #55

Earlier quoted context omitted.

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…

As someone also with ADHD, I can relate in a lot of these respects. The idea of doing pair programming every fucking day would ruin me. I really don't mind collaborating or discussing with people, because I think that's what our brains are great for, but not in the pair programming sense, and not every day. In my last job, I was very open about this, but my manager seemed to basically brush it off and pull up a chair…

> By chance, do you struggle with eating sounds in offices to the point where you panic?

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.

Re: Developers spend most of their time figuring the system out

#199

Post by rhizome » Thu, Mar 31, 2022, 1:35 AM UTC

creakingstairs wrote: post #147

toomanydoubts wrote: post #100

Earlier quoted context omitted.

Thanks for posting this. Yesterday I came across a job position on a company that does 100% mob(!) programming everyday¹. This means every programmer works 6 hours per day on a zoom call with 2 other programmers, rotating roles between typist, navigator and support every ten minutes. 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,…

> 100% mob(!) programming everyday 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.

what better way to ensure you get CS degreed ppl for positions that legally can't require one than to reproduce the "group project" model as an organizational principle?

Re: Developers spend most of their time figuring the system out

#200

Post by oddthink » Thu, Mar 31, 2022, 1:41 AM UTC

gleenn wrote: post #19

People 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…

I still don't really get pair programming. Maybe it's my inner introvert, but it sounds really draining. And what about all of the non-programming time during the day?

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. :-)