Live data from Hacker News

Developers spend most of their time figuring the system out

lepiter.io

331–340 of 418 posts

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

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

It is possible, the condition is a bit poorly named. The video of the talk by Russell Barkley that is linked elsewhere is a good primer https://www.youtube.com/watch?v=YSfCdBBqNXY). People with ADHD can have episodes of hyper focus. However this is a bit a misnomer, it's called Perseveration and is not really a good thing, and has more to do with one's inability to task switch (https://en.wikipedia.org/wiki/Perseveration). However it also allows you to completely zone into a code base or a problem. The problem is you don't really have much control over what will catch your attention. But of course you can develop quite some deep technical expertise this way.

Now, that said, there is a new movie, Everything Everywhere All At Once, and if you take this title as a stand in for ADHD, maybe you can see that while this way of living can be overwhelming it also allows you to have a pretty good overview over systems and how their components interacts very fast. I think that's what many ADHD'ers are actually very good at, grokking code bases or the gist of things very quickly. Systems thinking in general. Also quick recall / association chains...

Also, on average, the higher your IQ, the later in your life your ADHD diagnosis will be (see this video on adult ADHD https://www.youtube.com/watch?v=dVDhYtQkuO8). Your other abilities can compensate somewhat for your ADHD. Also of course when battling this condition you will build many personal tools and habits that neuro-typical people will never have to do, so in that sense you also might have a leg up in certain situations.

I'd say professionally the biggest problem is not so much on a technical level, but more on an emotional / impulse control level. ADHD'ers can come off as brash, speaking their mind freely, not being able to just put that comment in when it's better to shut up.

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

#332

Earlier quoted context omitted.

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

This is not about correctness but about ergonomics and clarity.

Consider the 'standard' definition of the complex numbers, whilst we know there are more intuitive options.

Consider tau vs pi. And how hard it is for anyone to write mathematics based on tau.

Consider the rather lacking notation for probability with conditionals.

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

#333

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 particularly, but having to deal with distacting sounds, pressure to focus, and feeling trapped in a cubical can definitely make me uncomfortably anxious.

Agreed. I've never been in a true individual cubicle thankfully. Only pod style ones.

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

#334

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…

This may work for simple tasks and mid level work. For complex and exploratory work I hate it.

I've been programming at various levels of abstractions and different stacks for 20 years. I often have very good intuition on diagnosing and solving technical problems. It's very hard to verbalize this, especially to people without the same background, it's intuition built on hours and nights of pain and debugging/googling/prototyping and I often need to search and REPL/prototype things to know I'm going in the right direction.

So I waste time dragging the other person along my mental path, and when I go into a wrong direction the cost is also increased by having to explain what I'm doing + the other person usually being annoyed at being dragged along for something they barely understood and it ends up being for nothing.

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

#335

Earlier quoted context omitted.

And then you have the common argument that comments are bad practice. If I can read 2 lines of comments for every 20 lines of code while navigating a large codebase until I find the code I really need to dive into, the productivity gains from that are nothing to scoff at.

Yeah, I don't even know what "self-documenting code" actually means. You don't write README.md, ARCHITECTURE.md, JavaDocs, etc, at all? A new developer is supposed to go through all the codebases and figure out for himself?

Self documenting code means carefully choosing names and structuring the code in a way that there is reduced ambiguity and maximum clarity instead of compensating for low quality code with additional documentation.

If your code is sufficiently clear there will be nothing left to say in the comments, the comments will have to repeat what the code is already telling you which significantly diminishes the value of comments.

>You don't write README.md

I don't think people are talking about self promoting projects or self documenting projects.

>ARCHITECTURE.md

or self documenting architecture.

>JavaDocs, etc, at all?

or self documenting libraries.

Seriously, what's so hard to understand about looking at code and then understanding it because you read it instead of having to read comments to understand the code that is in front of you? You seem to be under the wrong impression that self documenting code is a negative process where things are taken away rather than added.

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

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

And you select away anyone who does best in different environments, or who refuse to entertain working for you because of the enforced pairing.

Personally I can think of few things more exhausting and detrimental to my wellbeing than suffering through pair programming.

You can get most of the benefits just fine without it, with occasional sessions, without the cost of driving away people.

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

#337

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…

The only thing I find rude about this is that I don't see how it's relevant, and maybe that it implies it's an optional emotional response, or a recent one. I get where you're coming from, but it has nothing to do with software developers, and also who cares about their identity as a tough software developer more than their own sanity!?

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

#338
post #262

Earlier quoted context omitted.

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

I find it far easier to program in an automotive shop (banging, yelling, loud revving, etc) than in an open office next to someone slurping food every twenty seconds. Well, that's unfair, as in the former I had almost no problems getting into flow. I expect it's similar for people who like working in coffee shops.

Yep, absolutely true

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

#339

For an environment that's supposed to be about making things easier to discover, the glamorous toolkit website is pretty useless. Lots of bragging about how great it as, and lots of unreadable screenshots that do not interest me enough to actually download and install the thing.

What about these videos: https://vimeo.com/496004749 and https://vimeo.com/498735070?

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

#340
post #213
post #153

Earlier quoted context omitted.

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.

My algorithm for commenting is simple: If I don't understand what a line of code does, I delete it. If the behavior stays the same then it shouldn't have been there in the first place. If removing the line breaks something I put it back and add a comment explaining why it belongs there.
Post reply on HN