Live data from Hacker News

Developers spend most of their time figuring the system out

lepiter.io

301–310 of 418 posts

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

#301

Earlier quoted context omitted.

Pair programming for integrations or maintenance might be ok, but for new projects that is like having multiple people write a novel. Not only will it be pulled in many directions, it may eliminate some great innovations. Usually one person in the pair also has more influence politically in the company so they get their way. There is a reason why nearly all good programming languages, standards, platforms and even ga…

> Pair programming for integrations or maintenance might be ok, but for new projects that is like having multiple people write a novel. Not only will it be pulled in many directions, it may eliminate some great innovations. Usually one person in the pair also has more influence politically in the company so they get their way. This feels pretty relatable and sometimes also extends to code review, when another develop…

> Hmm, i don't like this for subjective reasons, you should rewrite it to be different

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

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

#302
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…

> People always struggle or avoid doing pair programming

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.

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

#304
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…

It sounds like a small project where everything can be remembered by everyone uniformly and perfectly and also people with specialty and exceptional talent into one or the other area are laid off, and everyone is uniform in level of capabilities and preferred area of activity (so it doesn't matter who sits with who over what). Sounds too idealistic where it never happens that two come together who are equally weak or even clueless of a big legacy code and it never happens that the session becomes a guessing game. : )

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.

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

#305

This sounds intuitively correct. It also leads to the unintuitive implication that paying down technical debt as soon as it arises and keeping systems simple and elegant as much as feasible, and well-documented wrt. inherent complexity, is not just key to software assurance and quality in general, but also to optimizing the use of developer time . Accidental complexity is not really manageable "debt"; it imposes larg…

Couldn't agree more.

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.

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

#306

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

That sounds like torture

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

#308

Earlier quoted context omitted.

I don't really buy that. 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…

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

> Things in mathematics once defined, tend not to change, even when changing would be beneficial.

Can you provide an example?

Mathematics definitely change as soon as someone provides a proof that something isn't correct.

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

#309
post #276

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…

(Note: I am not doubting in any way that you’re great at what you do and highly successful. Nor am I downplaying any difficulties and struggles you have had.) 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…

Attention-deficit hyperactivity disorder is poorly named. It does not necessarily imply an inability to focus. It's essentially a combination of impulsiveness and poor short-term memory.

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

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

#310
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…

Possibly dumb question, but... why do orgs need specific pair programming policies at all. Why can't you just ask questions and help each other as needed?

I know I'm going to get jumped but let's be real it's a cult behaviour that originates from the cult of extreme programming ("XP").

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.

Post reply on HN