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

311–320 of 418 posts

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

#311

Post by KronisLV »

dottedmag wrote: post #301
KronisLV wrote: post #288

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

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

Agreed, yet you're implying that:

  - there must be a guidebook in the first place
  - that it must actively be followed
Sadly, that is not the case in many environments, where disagreeing with another developer might actually make you waste more time discussing (or rather) arguing things back and forth, rather than just doing the changes that they want.

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

#313

Post by teknopaul »

falcolas wrote: post #24

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

Burn lombok with fire. Code you can't read, and cant debug, is horrible to work with.

I find the best was to make your code grokable, is to have junit tests for everything that run fast in the ide. When code needs maintenance, you can run it in the debugger quickly and see what it actually does, instead of what it was intended to do.

The worst Java code is lombok code that gets fsked by aop and/or hibernate. I call these abominations Nojos (not plain old java objects)

Again: burn lombok with fire. Wrong line numbers, ungreppable code, obsure bugs, different depending on the lombok version 70% maintenance cost compared against, two seconds to have your ide automatically make explicit the code you are going to run.

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

#314

Post by docmars »

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…

You described how I program and think in my job better than I could have ever dreamed. Thank you for articulating this!

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

#315

Post by navotgil »

bear8642 wrote: post #223
Mizza wrote: post #7

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

Indeed! Remember reading this https://raspi.tv/2015/documentation-and-commenting-your-code > article on importance of comments

2 different things https://swimm.io/blog/code-comments-vs-documentation/

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

#317

Post by necovek »

a9h74j wrote: post #114
switchbak wrote: post #107

Earlier quoted context omitted.

That kind of context switching sounds like it's horrible for just about everyone (including the business).

Perhaps some psychologist at Yale has embezzled $50 million and is using it to fund a startup for psychology research purposes.

I'd love it if it was that! :D

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

#318

Post by darkwater »

darkwater wrote: post #71
WindyCityBrew wrote: post #39

Earlier quoted context omitted.

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…

As others pointed out, for many of us pair programming is much more demanding on mental resources. The way I tend to work is by doing micro-breaks, checking out other things I would not be comfortable sharing with someone else; if I don't do that and keep hyperfocused, I get drained quicker. Also you can get a couple of programmers that will go down the wrong rabbit hole for much more time because they reinforce thei…

Also to expand on this, personally I found pair-programming easier on my mind when done IRL and not remotely. Sitting one next to the other has just more bandwidth available and spreading the communication over it makes it way easier for me. Remotely, I can do it for a 2, maybe 3 hour session and then I'm fried for the rest of the day (but usually those were 2-3 good and productive hours).

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

#319

Post by necovek »

dottedmag wrote: post #301
KronisLV wrote: post #288

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

It can work both ways.

It's unfortunate people are mostly conditioned to not oppose: whether to get branches landed faster, or simply because of the imposter syndrome, but some of us who are good at opposing and saying no sometimes struggle to find the right balance.

My goal when reviewing is to help others learn something new, which is why I'll sometimes share a personal, subjective preference for an approach (with "subjective" meaning that there are pros and cons to either approach with neither being better in every circumstance, especially in a legacy codebase like they all are).

I am trying to walk the fine line between teaching someone something potentially new, and not dumping on their velocity or self-confidence. I love it when people acknowledge the idea and say "nope", yet I understand that many won't do that, so most of the time, I stop myself from even sharing my subjective preference.

Outside of character, it requires building trust between people and not being out there to "prove your mettle", but to build stuff together. And with so much churn in jobs and remote work (I haven't met my new coworkers of 6 months yet, and I haven't met half the previous team either), that's sometimes hard.

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

#320

Post by irishsultan »

redisman wrote: post #296
_huayra_ wrote: post #221

Earlier quoted context omitted.

Having been on both the knowledgeable and noob side of this "pair programming onboarding", I find it to be fantastic. When furiously googling / grepping around the code to self-onboard, it is so difficult to see the bigger picture of how the system works; if someone can explain the architecture to you, you become much more self sufficient, very quickly too. On the "mentor" side of such pair programming, it is extreme…

> if someone can explain the architecture to you This should happen anyway - pairing or no. What kind of onboarding are people doing where architecture overview isn’t a part of it?

Explaining the architecture in the abstract and explaining the architecture while changing something to the application are very different things. Both for the explainer and for the person trying to understand and process the explanation.
Post reply on HN