Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Developers spend most of their time figuring the system out

lepiter.io

Post reply on HN
Print view View original

381–390 of 418 posts

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

#381

Post by luke_value »

kayodelycaon wrote: post #55
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…

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…

Man up. Stop being weak and making excuses.

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

#382

Post by bezospen15 »

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…

Haired programming is bogus. It's just another form of micromanagement invented by MBA types. They're constantly trying to make us more productive and forcing us to collaborate in uncomfortable ways. Our jobs are difficult, it should be done at our pace, not theirs

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

#383

Post by AtlasBarfed »

kayodelycaon wrote: post #55
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…

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…

100% pair programming is not compatible with deep thought and concentration.

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.

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

#384

Post by kayodelycaon »

sai_c wrote: post #374
kayodelycaon wrote: post #362

Earlier quoted context omitted.

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

Thank you very much for answering, although it is a very personal thing to ask about. 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.

It took a lot of time to optimize the process. Once you get used to understanding people individually, pattern emerge and you can generalize a few things. I have a number of mental guardrails like: If (person) is (things), then don't express (idea).

IF my dad IS talking about (politics|religion) THEN do not enter discussion.

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

#385

Post by bezospen15 »

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…

Paired programming is bogus. It is enforced by MBA types that are trying to get every last ounce of productivity out of us and forces you into uncomfortable collaboration scenarios. Our jobs are extremely difficult. It should be done at our pace in our environment, not theirs

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

#386

Post by tudorgirba »

sssilver wrote: post #12

Figuring out existing bespoke systems is what sucked the joy of programming out of my soul.

I see this perspective too often. The good news is that it does not have to be painful :). Looking inside the system can be beautiful if only we change the tools through which we look.

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

#387

Post by tudorgirba »

terbs wrote: post #297

Dang - from the way the article was written, I was really hoping to see some magic static code analyzer that would explain a system to a developer. But instead it looks like some enhanced version of Jupyter notebooks?

The proposition is not a tool, but an approach (moldable development). In a way, it is like data science, but for software. The approach was validated for more than a decade in industrial settings. Indeed, there is an environment involved to show how it can work in practice. It's understandable that one can see it as some kind of notebook, but it's really more than that. For example, there is a lot of emphasis on custom inspectors as basic pieces in the environment.

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

#388

Post by tudorgirba »

zwieback wrote: post #57

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

Interesting. We find the situation to be quite the opposite. The older and larger the system, the more expensive figuring out is.

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.

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

#389

Post by tudorgirba »

Pxtl wrote: post #263

Which is why as a code reviewer the legibility of the system is my top priority. I don't even care if the code works that'll come out in testing. I care if I can look at each section and understand what it's doing and why. And I'm utterly flabbergasted how many developers don't understand this.

Legibility is relevant. The problem is that legibility requires one to read. And one cannot read the whole code fast enough. That's why legibility is relevant in the small (~one screen). In the large, we can benefit greatly from other ways to summarize the system.

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

#390

Post by tudorgirba »

paulcole wrote: post #124

As a non-developer, this strikes me as funny. Like when Uber “invented” the bus. 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!

Interesting.

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.

Post reply on HN