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

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

#211

Post by mylons » Thu, Mar 31, 2022, 2:22 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,…

tangential question: I'm 37 and think I have ADHD. My partner thinks I do, and when I read posts like this I deeply identify with them. What should I do? Get a diagnosis? My ignorance thinks the only course after that is drugs which doesn't sound that appealing..

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

#212

Post by drawkbox » Thu, Mar 31, 2022, 2:25 AM UTC

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…

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 games are usually started and prototyped by one developer. That is because programming is creative value creation and business/finance/project managers passionately want it to not be, they want it to be a factory and it never was, is or will be that until the initial versions are out. They want to value extract before the value creation, they also try their hardest to make sure no programmer has much power so they are "swappable" which again is not true in product creation, maybe maintenance or once the base is created, but not initially.

Programming is a creative skill and should always be seen that way. Most product developers, game developers and full stack to presentation developers know this and can make some of the best value creation because they can take it from start to finish. Once it is prototyped or first versions, it can be ramped up for value extraction.

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

#213

Post by Izkata » Thu, Mar 31, 2022, 2:25 AM UTC

layer8 wrote: post #153

ggregoire wrote: post #136

Earlier quoted context omitted.

I think the argument is about comments like this // function to get the recipes function getRecipes() { ... } which are redundant and pollute the codebase. Where have you heard that writing useful comments (e.g. explaining an edge case, explaining a technical workaround, etc) is a bad practice?

There is a minority of developers who believe that code can and should be mostly self-documenting, and that comments should be avoided because they become outdated and nobody reads them anyway. For example: http://web.archive.org/web/20100415205750/http://blog.weapon...

Note that their bad example is comment-every-line style just like GP's example.

No-comment self-documenting code is largely a backlash to this style, which is how introductory coding courses teach (taught?) was the right way to do comments. For a lot of programmers who first started in in one of these courses it tended to stick because they were never taught another way.

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

#214

Post by Lownin » Thu, Mar 31, 2022, 2:26 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…

Fellow ADHDer here. That issue with eating noises is called misophonia. Check out the subreddit.

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

#215

Post by Lownin » Thu, Mar 31, 2022, 2:28 AM UTC

briandear wrote: post #198

brailsafe wrote: post #109

Earlier quoted context omitted.

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…

Misophonia is a real thing that is genuinely difficult to deal with for those of us who have it.

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

#216

Post by talaketu » Thu, Mar 31, 2022, 2:31 AM UTC

hn_throwaway_99 wrote: post #210

giantg2 wrote: post #102

In my experience, the biggest obstacle in understanding the system is that the underlying business process is not properly documented. A technical system is only as good as the business system it's implementing. Knowing the business process makes it much easier to understand the technical implementation, especially if you're trying to find bugs in the technical system since you can more easily see the mismatch betwee…

I disagree with this (sort of) for a couple of reasons: 1. For one, I think it's hard enough just to keep technical documentation up to date. Keeping separate business process docs up to date with code feels like it would be a collosal task. 2. That said, most software at least starts with some amount of requirements (whether that be a formal spec or a bunch of Jira epics). I have rarely seen any engineer start first…

Business data / process flow is so stable compared to a software implementation that having quality documentation pays dividends again and again. If you could document only one thing, document the business data flow.

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

#217

Post by giraffe333 » Thu, Mar 31, 2022, 2:35 AM UTC

One place I worked, the rule was "always have two pairs of eyes on code". Each team got to decide whether that rule was met with some mix of mob or pair programming, or just code reviews/pull requests. We could change depending on the needs of the project and team members. If management forces any of these options on teams it is a huge mistake. The point of pair programming is to share knowledge, reduce bugs, etc. and making it into a metric to measure teams by doesn't work.

It's a lot like setting a minimum code coverage rule like 80 or 90%, people end up cursing the rule as it makes them do stupid things to satisfy the rule. Code coverage is one great tool to explore where your code needs more tests, but it's not the only one, and it's not the point. The point is writing code that's easily maintained, safely changed, and can be delivered to meet customer needs.

You hired really smart people (hopefully) and you should let them decide how to work.

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

#218

Post by formerkrogeremp » Thu, Mar 31, 2022, 2:35 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…

From an accounting perspective,if your business isn't a SaaS or similar, why are developers anything but a cost center?

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

#219

Post by ajmurmann » Thu, Mar 31, 2022, 2:35 AM UTC

rhizome wrote: post #199

creakingstairs wrote: post #147

Earlier quoted context omitted.

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

CS group projects are biting like pair programming. Most CS group projects I've been on were a game of chicken where everyone would wait for others to do the work. If you don't pull your weight on pair programming it's quickly obvious and you'll get feedback.

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

#220

Post by repiret » Thu, Mar 31, 2022, 2:36 AM UTC

rhizome wrote: post #199

creakingstairs wrote: post #147

Earlier quoted context omitted.

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

In what situations (and jurisdictions) would an employee be legally prevented from requiring a CS degree?