Live data from Hacker News

Developers spend most of their time figuring the system out

lepiter.io

181–190 of 418 posts

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

#181

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…

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

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

#182
post #104

Earlier quoted context omitted.

You are correct in that having two people both well-versed in both the system and the change they are making is a waste. However, that tends to be rare - the more common situation on a team with no newbies is that you will need to solve new problems with new methods, possible integrating with new systems. If you have a team of experts, and you want to keep them all experts, it's much more economical to have two peopl…

I'm not seeing anyone mentioning what you should do in the case where the one person that knows the code gets hit by a bus. Would anyone ever say you only need one copy of the code, because backups are inefficient?

Hire a professional to pick up where he left off?

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

#183

Earlier quoted context omitted.

See also Bill Thurston's commentary on the nature of mathematical knowledge: "mathematical understanding does not expand in a monotone direction. Our understanding frequently deteriorates as well. There are several obvious mechanisms of decay. The experts in a subject retire and die, or simply move on to other subjects and forget. Mathematics is commonly explained and recorded in symbolic and concrete forms that are…

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…

I work in the field of cryptography and I agree with GP, papers and research goes in all sorts of direction, but very little actually ends up forming a solid branch of knowledge. Sometimes if people aggregate into such a branch, there’ll be SoK papers (systemization of knowledge) that will start popping to make the tip of that branch understandable, and at some point people will create all sorts of resources including university courses and textbooks. But that’s rare, and it demands a lot of hypes, and sometimes tips of branches just go overlooked for a long time. If the author dies or move on, it’s possible that nobody can really take over the work easily, because there’s no proof, or nobody understands it, etc.

Afterall, this is what happened to a lot of famous mathematicians. Their texts were forgotten, and then rediscovered a very long time later, and sometimes proofs could not be recovered for a long time (cf Fermat)

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

#184
post #153

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

> Where have you heard that writing useful comments (e.g. explaining an edge case, explaining a technical workaround, etc) is a bad practice?

They are pretty clear about "useful comments" - by what they wrote, it sounds like they already understand what you wrote.

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

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

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

#186

Regarding pair programming - I'm a self-taught freelancer based in a remote area (not many local devs). How might I bring about the benefits of pair-programming or even mentorship in a remote context? Mentor As A Service? Sounds a little lame to be honest.

Work on a project remotely with another dev.

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

#187

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

I went to that interview a few years ago. I got to experience the mob live programming interview. It sounded bad going in but things often turn out better. It felt like I was live streaming on twitch with a small disinterested following. Hard to imagine 6 hours a day in that state. It feels like one of those places that will make you rethink if you want to remain in the industry.

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

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

Things happening "always" or "never" are usually the cause of discomfort. Hard rules about 100% pair programming or opposite make things worse in long term. Starting with a "buddy" on team/ work switch almost always helps. After that, it's mostly 'it depends' thing. We must be conscious about what works best for the individuals and teams and should settle around the the sweet spot. Excess of anything is unhelpful.

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

#189
post #80

Earlier quoted context omitted.

A couple of things I found helpful along those lines: * Data storage: what does the schema look like? Even if it is not persisted to a relational DB, is it possible to draw out a schema of a data model and all the relationships ("JOINS") * Add logging to code you are trying to debug but are hard to understand and repro bugs for in production. Once you have logs about the full state that reproduces the error, the issu…

> Add logging to code you are trying to debug This is a great idea and should absolutely be a standard. There's a whole logging level ("DEBUG") devoted to this that I think goes way underused. Another, related idea is to use a debugger. Using PDB for Python codebases has sped me up A LOT.

I worked with software where you could change logging level dynamically, per subsystem.

The ability to switch to DEBUG level, get a wall of text from a problematic spot, and switch it back to WARN was very, very helpful for troubleshooting prod.

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

#190

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

[deleted]
Post reply on HN