[HN Gopher] Developers spend most of their time figuring the sys...
___________________________________________________________________
Developers spend most of their time figuring the system out
Author : webmaven
Score : 253 points
Date : 2022-03-30 17:34 UTC (5 hours ago)
(HTM) web link (lepiter.io)
(TXT) w3m dump (lepiter.io)
| smm11 wrote:
| Took me eight months at a government gig to figure out how the
| system worked - much less how it was set up, then I left three
| months later ...
| tromp wrote:
| > we should start by talking about how not to read code. We
| cannot afford not to.
|
| Nice triple negation there...
| sam0x17 wrote:
| This seems like a really, really good justification for the Rails
| Way of having a sane and predictable app file structure and
| layout where developers who have never seen your code before can
| jump in on day one and figure things out very quickly.
|
| Would love to see more web frameworks adopt this opinionated
| methodology to save us all some time.
| kingcharles wrote:
| It's getting so far from the original web coding I did in 1995
| where you had a .html file, to modern frameworks where 99% of
| the underlying code is in a hidden file nested 17 levels deep
| that is an interface to a virtual class that exists only in the
| imagination of the framework creator.
| dep_b wrote:
| I spend about 60% of my non-meeting time fighting with broken
| tooling that was supposed to make my life easier.
| pjerem wrote:
| Let me guess, 60% of this time fighting with broken tooling is
| in-house tooling. But I feel you. You are not alone.
| zwieback wrote:
| 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 to throw all types of
| projects into one pot. If there's a case to be made that mature
| code bases require less "figuring out time" then organizations
| should discourage jumping on the latest technology "just
| because".
| gleenn wrote:
| 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 times faster than screwing
| around by yourself. Pointed-haired bosses and accountants will
| never understand this. If you pair and rotate, the inexperienced
| person becomes experienced quickly, and it 's viral if you also
| do rotating pairing. A team with one expert and pairing is now a
| team full of experts.
| SomeCallMeTim wrote:
| 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 incredibly high turnover that the period
| to transform a developer into an expert is close to or less
| than the average tenure of an employee, in which case your team
| has _other_ issues that likely need to be addressed, because
| why are people jumping ship so quickly if it 's such a great
| place to work? (For example: If it takes six months to produce
| an expert, you'd need to have an average tenure of less than or
| equal to six months to _really_ benefit from pairing; anything
| more and the 50% performance penalty has to eat into your
| overall productivity.)
|
| On top of that, I have never been at a job where it's taken me
| more than a week to get up to speed on a system, or at least to
| the point where I can simply ask the occasional question of the
| experts on a team to get me unstuck. Even if the average
| developer took a month or two, pairing beyond that point is
| simply fun and not more productive than two programmers
| developing independently.
|
| Unless one of the developers is otherwise likely to produce
| negative productivity on their own, I suppose. I've worked with
| that kind of developer as well, and the right answer is to
| eject them from your team, not pay other developers to babysit
| them.
| zozbot234 wrote:
| True expertise on a large, complex code base does not just
| take a few months; competence is best modeled as growing over
| long timespans, not as something that quickly reaches an
| "expert"-level ceiling. This is all the more true when-- as
| is often the case-- the codebase is a complicated legacy
| thing, full of accumulated "technical debt" and unneeded
| complexity of all sorts. This is not to say that 100% pair
| programming is always the answer, but doing it to _some_
| extent is likely warranted.
| WindyCityBrew wrote:
| 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 that fond of it, and 2) most managers do
| some quick gut check mental math and assume 2 programmers + 1
| computer can't be equal to or greater than 2 programmers + 2
| computers, that's nonsense, actual evidence be damned.
|
| edit to add: I agree with commenters that pairing is more
| demanding/draining than solo work. I shudder at the thought
| of anyone trying to pair for 8hrs straight, or "all day every
| day 40hrs/wk". Nobody solo programs like that either though.
| darkwater wrote:
| 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 their wrong belief mutually. This obviously
| happens with individuals as well but if you get the wrong
| mix it can be much worse.
| raverbashing wrote:
| I agree with the benefits
|
| But you also have 2 developers using 100% "of their cpu"
| during that time, which is really unsustainable for longer
| periods.
| Keyframe wrote:
| One of threads is reviewing code as well, which would be
| done later on anyways.. among other benefits. I'm
| invoking commodore64 days for the second time in a row
| now - back then, during the war, as kids we didn't have
| much comouter lying around so few of us gathered around a
| single one and learned and tinkered with it. It was
| awesome since everything bounced out loud from multiple
| brains. XP in general is alright but maybe not all of the
| time, as with anything.
| jfk13 wrote:
| I've done "pair programming" a few times, with (I think)
| great effectiveness, but (a) it's been in a very specific
| context, where we each brought substantial but not-fully-
| overlapping expertise to the task ( _not_ pairing a
| newcomer and an experienced developer); (b) it was an
| entirely voluntary thing that the two of us decided to do,
| not something imposed on us by management; and (c) it was
| for short "sprints" of no more than a few days, not for
| extended periods.
|
| If it became a required part of daily work in my company, I
| don't think I'd be around for long.
| a9h74j wrote:
| Interesting question then:
|
| For what characteristics of problem is pair programming
| more useful, when such problems arise? Is there a pattern
| to plan for?
| depr wrote:
| Can you provide this evidence?
| caseyohara wrote:
| https://tuple.app/pair-programming-guide/scientific-
| research...
| NaturalPhallacy wrote:
| There's no way that isn't biased as that company's
| product is pair programming software.
| azemetre wrote:
| I don't mind pair programming but I don't have the
| physical/mental capacity to do it for a full work day. I
| can only imagine how exhausted I'd get after several weeks
| of it.
|
| When I do pair, I only work for 3 or 4 hours that day
| total.
| Tabular-Iceberg wrote:
| Pair programming is one of the smartest inventions in
| this field, but I wouldn't dream of advocating it for
| this reason.
|
| The best model would be four hours of pair programming
| and another four of paying those programmers to take a
| long lunch, a nap and a walk. Those 4 keyboard-hours
| would probably be as productive as 16 keyboard-hours of
| the same programmers working independently for a full
| day, if not more. And unlike full time pair programming
| it would be sustainable.
| teknopaul wrote:
| 3 or 4 is just fine. I worked at a place that only did
| pair programing, but quite often we would break up to
| write docs fill out jira issues and do all the other
| stuff that's needed. Recently we did 3 way programming
| once a week for 1 to 3 hours and it still had a lot of
| the benefits. Not sure being absolutist is a good
| approach to anything in our field.
| fragmede wrote:
| Therein lies the problem. How much is an avoided bug
| _really_ worth? A > where really a >= is needed is
| theoretically going to get caught with pair programming,
| but how do you make that a metric you can track when we
| still don't have any way of measuring developer
| productivity. We never got past the fact that measuring
| lines of code output is dumb, to any other sort of metric.
| Even if we had such a metric (using magic, perhaps), would
| programmers actually welcome it?
| hallway_monitor wrote:
| 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_ people
| learning the new code as it 's being written. Theories about
| what might or might not be helpful have very little value
| until tried in the field.
| pixl97 wrote:
| 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?
| joshuacc wrote:
| Having worked at both a mid-size EdTech company and now in a
| smallish part of Microsoft, every codebase for public-facing
| software that I've seen would take at least 1 year to achieve
| actual expertise in (while guided by an expert!) and would
| probably take much longer.
| NewEntryHN wrote:
| It's developers who don't want pair programming, because
| they're introverted and don't like it.
| bufordtwain wrote:
| Maybe the sweet spot is to have someone pair with an expert
| when they are getting started and when they are struggling to
| understand things. Personally when I pair program I use a large
| fraction of my brain to interface with the other person. This
| leaves me much less brain power to work on the actual problem
| at hand. And it's far more exhausting to me than working alone.
| kayodelycaon wrote:
| 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
| work on problems in order. I visualize everything like a house
| of cards. I see everything at once and load random parts of
| what I'm looking at until I see the whole thing in my minds
| eye. (Because I have three logical registers on a good day.)
|
| Asking me to explain my thinking requires me to restructure the
| process in reverse and put it into a linear thought that can be
| understood by someone else. Which half the time dumps all of
| the registers in my short term memory. Meaning I don't
| understand what I was looking at. Communicating with neuro-
| typical people is frustrating, mostly because I try really hard
| to communicate clearly. (Good communication means better
| relationships with coworkers and less wasted code.)
|
| Despite the complete chaos in my brain, I write extremely good
| code (by other people's measures), because I think about
| readability, algorithmic complexity, side effects, testability,
| and a thousand other minor details at the same time. Tests come
| in once I'm happy with the structure. (I hate working without
| clean understandable tests!) Then I refactor to clean up the
| code and comment to explain reasons why it was written specific
| ways, so coworkers (or future Kayode) don't want to murder me.
|
| If this comment is a bit rambling, you know why. :)
| cromka wrote:
| By reading this I think I just realized I have AHDH, and also
| problem with short-term memory. Damn, need to talk to a
| specialist about it.
| zarmin wrote:
| As someone with ADHD and memory issues, your comment is what
| I hope my future looks like. Would you mind expanding on how
| you're able to work through ADHD symptoms, motivation issues
| and such?
| drc500free wrote:
| In terms of overall mindset, I've found it helpful to think
| about my month as a portfolio of days. Some will be hyper
| productive. Some will be almost nothing.
|
| This has helped in two major ways. I've let go of the idea
| that the hyper productive days are my natural state, and
| that the 90% of the days that aren't there are some kind of
| failure. I've also built my career to avoid having daily
| accountability and prefer weekly/monthly.
|
| That mindset shift, separate from the daily "how do I get
| stuff done" tactics, has really helped prevent the kinds of
| negative spirals that adhd can put me through.
| toomanydoubts wrote:
| Awesome. I haven't optimized my career this way yet but
| accepting that some days I will code 16 hours straight,
| and other days I won't even look at my laptop has done
| wonders for my anxiety caused by seeing everyone with a
| constant productivity and seeing myself in this daily
| rollercoaster.
| kayodelycaon wrote:
| Mine is comorbid with being bipolar. The only thing that
| helped was medication and then...
|
| - Learning CBT from a book with the help of a therapist to
| guide me. https://www.amazon.com/Feeling-Good-Handbook-
| David-Burns/dp/... The core of it is in the first few
| chapters. Never read the later ones once I got the concept.
|
| - Learning how to have realistic expectations about what I
| can do day after day.
|
| - Prioritize self-care and optimize for long-term
| performance over short term success. This includes going to
| bed earlier than I want. :(
|
| - Working with my manager to have the proper
| accommodations. In my case, strict 40-hour work week, no
| work interruptions outside of that, and time off as needed.
|
| I've needed accommodations less since things have evened
| out, but I'll never be able to do on-call.
| yonaguska wrote:
| Medication and note taking helped a lot with me. Even
| better, a good note taking app since my handwriting is
| garbage, right now I'm using OneNote and I keep it pinned
| to every desktop separate from my code.
|
| Motivation- you need to actually align your tasks with an
| actual concrete personal goal or sense of accomplishment.
| And be invested in the work. Lacking that, you'll be
| dependent on external stressors to get anything done, which
| will reflect poorly on you if it gets to that.
| zarmin wrote:
| Thank you. I do rely on medication and note taking apps
| (though mine are a bit scattered).
|
| One of my issues with motivation is what you mentioned: I
| really really struggle to get invested. Things that are
| "work" seem to live in an anti-motivation bucket,
| regardless of how organically interesting they may be to
| me outside of a work contest. I'm in my 30s now, and I've
| been doing this my whole life and it is killing me. It
| takes a tremendous amount of effort and an extremely
| imminent deadline to get me to start anything. This
| (ostensibly) runs completely contrary to my self-concept
| and value system, but the motivation problem permeates
| every fucking inch of my life, and always has.
|
| I can read this back and recognize a defeatist attitude,
| but I don't know what else to do.
| kayodelycaon wrote:
| Motivation. Forgot to mention that. Without it,
| everything is so much harder. :)
| eterm wrote:
| As someone else who struggles with these things, I actually
| found pair programming helps a ton.
|
| Any time I get too distracted and drift off there's someone
| to nudge me back into focus. Occassionally I'll have to
| apologise and just say, "Sorry I didn't catch any of that"
| which sometimes takes a lot of understanding on their part
| to not be offended.
|
| There are some days where I struggle to explain things
| which is very frustrating especially for architecture type
| issues. I also struggle to actually build anything from
| scratch, and definitely have a brain more wired for
| destruction than creation.
|
| Secondly, you need to find an understanding workplace. The
| best places I've worked have been understanding of the fact
| that some weeks they'll get less out of me than a freshly
| hired junior because other weeks I'll do some very good
| work.
|
| It helps if you can have a niche, and helps if you can
| start off making a good impression. For me that niche is
| more of a bug finding and security focus. On weeks I'm
| feeling very motivated I can spend my extra energy being
| useful finding security holes and general bugs. Good
| managers will see the value from that.
|
| If you tasked me with writing even the most basic "todo
| list" web-app from scratch you'd probably find me after a
| week deep in analysis paralysis still deciding between
| frameworks having not written a thing, but give me the
| simplest "todo list" web app even one that's too simple to
| have bugs I'll have found something wrong with it before
| the day is out.
|
| But everyone is wired differently, so your niche might be
| the building side. Just work out from experience what your
| strengths are and lean heavily into them, or at least
| strong enough to get a reputation than you're good at your
| job, but not so heavily you get pigeon-holed in a role.
|
| And if it's just not working for you, don't be scared to
| just quit and find somewhere else. There are good and bad
| workplaces, and a surprising amount of advice is from
| people who have only ever worked 1 or 2 jobs at most so
| don't actually necessarily have the experience of different
| workplaces to be able to back up some of their assertions
| so take all advice with a pinch of salt and work out what
| works best for you.
| brailsafe wrote:
| 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 whenever he felt that was cool. "Time for
| pair programming". Bleh, thankfully I burnt out and got
| fired.
|
| I've been following a very similar path as you describe in
| your last paragraph, and I'd be very curious if there are
| other similarities that differ from how others write code.
|
| By chance, do you struggle with eating sounds in offices to
| the point where you panic?
| ratww wrote:
| I don't think I have ADHD, but I burned out pretty quickly
| after a few months of 8h/day pair programming. I started
| taking medication and took some extended vacation.
|
| Thankfully the CEO of the company wasn't much into it, so
| he forced our pointy-haired boss of a manager had to make
| it optional.
|
| The whole team unanimously decided to never do it again.
| brailsafe wrote:
| This almost made me tear up. I've genuinely never thought
| before this thread that there were companies that did
| this, and that it's just not a big deal to people with
| decision making power. I don't do anything for 8 hrs a
| day, but if I had no choice but to be doing 8 hrs per day
| of pair programming, I'd really be having some dark
| thoughts. Not exaggerating, this scares the shit out of
| me. Thanks for sharing. I actually feel like I need to
| step away from my computer and relax a bit just trying to
| imagine myself in that position.
| lvl102 wrote:
| I agree with this comment. Not all problems can be solved
| this way. Sometimes I need to sit down and think without
| constant interactions. Interactions are great but they have
| bandwidth limitations for the most part.
| legutier wrote:
| i have ADHD too, and have the same problems. In fact i'm
| assigned into one-person team in my company because i work
| effective in that way. My feedback is always 10/10 by my
| managers, but i think i couldn't work that good with such
| things as pair programming.
| aendruk wrote:
| > Because I have three logical registers on a good day.
|
| That's a fun way to put it. When encountering the usual
| brain-computer metaphors, I've always felt like I relate more
| to the Turing machine scanning over its strip of tape.
| Gravityloss wrote:
| Text is linear. Would drawing be an easier method for you to
| explain something? It often is for me.
| kayodelycaon wrote:
| Not really. But I'm glad you asked!
|
| Google "crazy conspiracy board meme" and you'll have a good
| analogy for what's happening. If I start writing it down,
| things randomly disappear from board. Which requires me to
| look at the gaps and fill in the blanks.
|
| You can imagine what this looks like from the outside. My
| dad has interrupted me so many times with "get to the
| point" and the only response I have is "working on it."
|
| The funny thing is... I'm an author and prefer to work with
| text.
| Gravityloss wrote:
| Yeah, for mind map style note taking I use hierarchical
| bullet lists. It's the same topology (if there are no
| cycles) without having to worry about layouts, and you
| can have both hands on the keyboard. I go up and down a
| lot and move blocks around.
| kevin_thibedeau wrote:
| You waste your time managing visual presentation (more so
| than 1D text). Schematic entry used to be commonplace for
| FPGA and ASIC development in the 90s. The industry has
| mostly moved to HDLs for digital logic because it is more
| productive and you get side benefits like revision control,
| easier reusability, and tooling independence. Anyone
| promoting 2D visual development for programming is selling
| snake oil.
| Gravityloss wrote:
| We're not talking about programming here but explaining a
| concept.
| toomanydoubts wrote:
| Thanks for posting this. Yesterday I came across a job
| position on a company that does 100% mob(!) programming
| everyday1. 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, the filter indeed worked out. As someone
| with ADHD, I couldn't last a single day on a job like that.
|
| [1]: https://engineering.meetsoci.com/mob-programming
| switchbak wrote:
| That kind of context switching sounds like it's horrible
| for just about everyone (including the business).
| toomanydoubts wrote:
| Honestly, it's sounds kinda insane. Mob programming
| certainly is a tool with its good use cases, like maybe
| tracking a bug, onboarding a new team member or making
| critical changes to core stuff. However, I just can't
| imagine having three engineers making 100k+ sitted
| together everyday on a single laptop to write yet another
| REST api or whatever.
| a9h74j wrote:
| Does Zoom have a "Mutex" button for obtaining keyboard
| access?
| a9h74j wrote:
| Perhaps some psychologist at Yale has embezzled $50
| million and is using it to fund a startup for psychology
| research purposes.
| adhd3 wrote:
| Thanks I also have adhd and this comment was illuminating
| BFLpL0QNek wrote:
| You just put in to words that I couldn't, exactly how I work
| and think :)
| ineedasername wrote:
| Echoed. I've done very limited task-specific paired
| programming and it's been okay, and I got enough out of it
| to see how it may be a good way of operating for some
| folks, but not as a matter of routine for me. It would be
| awful. I just don't approach problem solving in a way that
| lends itself to having to communicate what & why I'm doing
| something a certain way _as I do it_. It takes too long to
| explain. After the fact? Sure, I can explain and document
| quite clearly, but not while peeling the onion and
| sometimes boring through a few layers to come out of the
| current one at a different point. I don 't think this makes
| me better or smarter, just a different method.
|
| I think the GP post (GGP?) about the utility of sharing
| expertise is a good one, though I think that can be done
| w/o it being 100% all the time as well. It probably also
| depends on the nature of the tasks and complexity of the
| system. There may be jobs that really do optimize better w/
| a lot of paired programming, and I'm just not a good
| candidate for those roles. We all have different niches in
| which we achieve our best performance.
| a_t48 wrote:
| I keep putting off getting a formal ADHD diagnosis, but this
| sounds a lot like me. :) My programming/thinking style is
| very instinctual and doesn't really fit any sort of linear
| style. I kind of put things together as I go, trusting my
| subconscious to get all the little details together. I can
| explain post hoc why I wrote something a certain way, but
| won't be able to do it beforehand.
| wellpast wrote:
| I'm at a mandatory-pairing-multiple-times a day place right
| now and I've made the same observations you are identifying
| here.
|
| Pairing may be good to some degree for knowledge sharing but
| it works against good architectural design, which requires
| the kind of holistic thinking you describe, as well as kind
| of micro-iterative whittling away at the problem that
| interactive pairing couldn't ever achieve. In addition, the
| n^2 communication lines yield the worst effects of Conway's
| Law https://en.wikipedia.org/wiki/Conway's_law
|
| Nearly all of the computational problems we face in industry
| (save a narrow class of specialty problems) can be pretty
| easily articulated in the "macro" sense: "oh, we'll just have
| this distributed actor invoke that one and he'll reply with
| the blah, blah state".
|
| Look, we just paired and collaborated on a design, cool! But
| the reality is that none of the hard parts have been solved.
| The hard parts are always the unanticipated errors, edge
| cases, invariant violations that beset every system--a large
| set of issues that need to be made airtight when it comes
| down to actually putting the code and tests together, and
| these require the holistic thinking you're talking about or
| either you get subtle bugs or otherwise a mess is made in the
| code.
|
| As an industry we've gone so hard on coming up with social
| processes to "knowledge share" (pairing etc) and do things
| like audit for defects (code review process), but all of
| these are ultimately compensatory measures for bad design and
| bad code; and, in fact, as you suggest, they kind of
| encourage and trend toward bad code.
|
| A different approach to building systems socially would focus
| on the code being decoupled and articulated such that the
| barriers to entry would not _require_ pairing and these other
| processes. Decouple and compose components that can be
| understood at face value and in situ.
|
| But this is very hard and requires _extensive_ practice and
| expertise, something our industry isn 't keen on talking
| about. We like that quick race to "expert beginner" wherein
| we can say "Phew, now I'm an expert". So instead of focusing
| on mastering these we go for least-common denominator
| processes, which if you think about it is what pairing, and
| many of our processes are,- least common denominator.
|
| The truth is we're social creatures, so I don't think we'll
| ever get out of this state. Social processes will win not
| because they optimize the problem space but because most of
| us love and crave the interaction. My only lament is that we
| don't call the spade a spade and we try to argue that these
| processes are necessary for optimization when they really
| impeded optimizations and create downstream frustration and
| limitations.
| vonseel wrote:
| I'm also a programmer with ADHD.
|
| IMO, pair programming is most useful for short design
| discussions and mentoring, like explaining a better way to
| architect a feature to a junior engineer. I look back on
| these experiences fondly, and this type of collaboration
| helped me grow a lot as a developer.
|
| I don't feel like I get the concentration and focus
| required to "put the whole code implementation in my head"
| when I'm pairing, so I don't really see how it can be used
| 100% of the time to build systems efficiently.
|
| And regardless of whether it's a good way to work or not,
| many engineers just won't want to have someone looking over
| their shoulder 24/7. That kind of environment would drive
| me mad. I need to be able to drown out the world and bury
| my head in the code, and most of us don't work on code the
| entire day. I like having the freedom to read an article or
| browse the web for a bit whenever I want to fuck off.
|
| Pair programming and mob programming are definitely not for
| me, and there's no way I would take a job that requires
| doing either most of the time.
| bdamm wrote:
| Good design and getting everything right up works right up
| until the requirements change and the design no longer
| meets the ask. Unsurprisingly, teams might not even know
| all the requirements when building something new. Having
| everything orderly up front is a pipe dream.
|
| That said, there are definitely cases where sitting back
| and thinking through a design is a really good idea. In my
| experience, it's 1/10th of the job.
| ashtonkem wrote:
| The issue with pair programming has always been that some
| people hate it with the heat of a thousand suns. I'm one of
| them. Its very effective I don't dispute that, but it makes me
| absolutely miserable and I'll end up quitting to avoid doing
| it.
| akhmatova wrote:
| _When I worked at a place that did 100% pair programming with
| rotation every day, a new developer could hit the ground
| flying._
|
| Right -- because they're not the ones actually doing the work
| of course. Aside form the typing "work".
|
| _A team with one expert and pairing is now a team full of
| experts._
|
| Minus the ones who quit (or never joined) because they just
| can't get behind the insanity and teeth pulling that is
| (involuntary) PP.
| babyshake wrote:
| One side effect of pair programming frequently is it probably
| helps make you perform much better during job interviews with
| coding and system design questions.
| watwut wrote:
| That developer was not hitting the ground running. That
| developer was being carried by someone else in speed lower then
| that someone else normal speed.
|
| And also, pointy haired bosses and accountant don't mind pair
| programming all that much. Normal average developers with
| normal average psychology do mind it, object it, hate it.
| strken wrote:
| I like situational pair programming, but there's no point in
| forcing another senior developer watch me e.g. set up a toy
| repo to track down a bug, when we both know what error I'm
| currently getting and what I'll be doing. You have to be able
| to pair when you need it and stop pairing when you don't.
|
| For me, pair programming carries the implication that you're
| always doing it, which seems almost as bad as never doing it.
| epolanski wrote:
| I work in a team that leans heavily on pair programming and
| it's a night and day difference for productivity.
|
| Besides the domain and system knowledge sharing, besides
| exchanging productivity tricks or new ways to solve problems,
| it is much less distracting. I strongly believe that on any
| non-trivial task pair programming accomplishes much more
| business value (more tasks done) and growth than having the two
| developers working solo.
|
| I don't think it should be the _only_ way to work, but a
| significant part of each sprint should be done in pair
| programming.
| phendrenad2 wrote:
| It's hard to be scientific about this because there's no
| control group. If we clone your team and forbid them from using
| pair programming, in 5 years, which team will allow new
| developers to hit the ground faster? Which will have greater
| velocity. Which will have better code quality?
|
| Some downsides to pair programming I've noticed:
|
| 1) People can tend to jump to the first solution they find, in
| order to not look slow or stupid. This doesn't allow for time
| to refactor the solution.
|
| 2) It can promote a culture of "spoken-word documentation"
| where all information about the system is conveyed via word-of-
| mouth, and nothing is recorded. You can see how this isn't
| scalable...
|
| 3) Not everyone has perfect internet, desk setup, comfortable
| chair, microphone quality, monitor resolution, etc. and it can
| lead to one person mumbling and another just going "yup uh-huh
| yeah"
| redisman wrote:
| I just don't like pair programming. It feels like peer
| micromanagement to me. Thankfully I've only had to do it a few
| times.
|
| If we need to collaborate then let's hit the whiteboard but
| please afterwards let's work in peace on our own computers like
| civilized humans.
| pjmlp wrote:
| We avoid doing pair programming, because personalities matter,
| and this circus about driver and co-pilot is yet another
| "agile" marketing gimmick.
| ChrisMarshallNY wrote:
| Pair programming is one answer.
|
| So is retaining engineers, so that, once they learn the system,
| are available to maintain/teach it, and _more importantly_ ,
| are invested in doing a good enough job, because they will have
| to be around to deal with the fallout, if it was not a good
| enough job.
|
| There's no one answer, but I'd suggest that having an
| environment that retains engineering talent, and incentivizes
| good, long-lasting work, could be helpful.
| irrational wrote:
| Pair programming only works when both people have similar
| mental aptitudes/personalities/types/processing-speeds.
|
| The times I've been involved in pair programming it has been a
| disaster. I need time to sit there and think and process while
| the other person is getting bored and wants to keep going or
| they start to talk which ruins my thinking so I have to start
| over again.
| Veuxdo wrote:
| You don't think this depends at all on the particulars of the
| developer(s)? E.g. their personalities, experience, skill
| level?
| SomeCallMeTim wrote:
| The studies I've seen about pairing show that it's OK for
| beginners or lower-skill developers, but absolutely less
| productive for expert/senior developers.
|
| So yes, you're correct.
| JohnKacz wrote:
| Forgive my possible laziness in searching, but do you by
| chance have links to some of the studies you reference?
| dgb23 wrote:
| I would say that there is still a benefit of pairing an
| expert with a novice now and then. Not for productivity but
| for long term effects. They cannot be _too_ far apart
| though.
| jkaptur wrote:
| There are high-profile cases of world-class developers
| pairing: https://www.newyorker.com/magazine/2018/12/10/the-
| friendship...
| rednerrus wrote:
| It seems counterproductive to have developers on your team
| who aren't capable of collaborating in this way.
| Veuxdo wrote:
| There's a chasm between "developer who always pair-programs
| all the time" and "developer who isn't capable of pair-
| programming".
| erik_seaberg wrote:
| I need to quiet space to think (or at least thick
| headphones) to solve hard problems. I can't understand
| how some people work without ever getting that. Do pairs
| agree to shut up until someone gets an idea?
| stretchwithme wrote:
| I naturally prefer to do things on my own but I also find
| interaction with others satisfying. And I'm glad when it's over
| :-)
|
| In my current job, everybody is remote and you can't even play
| foosball with people on your team.
| verve_rat wrote:
| In my experience a team with one expert and pairing quickly
| becomes a team with many so-so members and an expert facing
| burnout.
| danielvaughn wrote:
| Onboarding buddies are the best.
| uoaei wrote:
| This sounds great if you expect high employee turnover, but by
| that point, I'd be investigating the reasons for that rather
| than only addressing the symptoms.
| PragmaticPulp wrote:
| Pairing is actually great in limited scenarios where one person
| is an expert and the other needs to ramp up quickly from their
| knowledge.
|
| But at steady-state, it becomes a drain on efficiency.
|
| In my experience, forced pairing is something that a small
| percentage of people love but it burns most others out. Every
| company I've seen try to force full-time or even most-time
| pairing on people has quickly lost a lot of their good
| developers. Although on the plus side, they at least have a
| system in place for quickly ramping up new developers as they
| join to fill all of the openings.
| codr7 wrote:
| Even then, people are different. Pairing for me is good now
| and then, but I need time on my own in between to figure
| things out my way. It's like hybrid work, nice as an option.
| I once had a boss who tried to force me to pair program with
| him at his convenience to check up on me, had.
| zozbot234 wrote:
| This sounds intuitively correct. It also leads to the unintuitive
| implication that paying down technical debt as soon as it arises
| and keeping systems simple and elegant as much as feasible, and
| well-documented wrt. inherent complexity, is not just key to
| software assurance and quality in general, but also to
| _optimizing the use of developer time_. Accidental complexity is
| not really manageable "debt"; it imposes large and growing costs
| over time.
| holoduke wrote:
| Developing is constant problem solving. Inside the app domain and
| also outside. Nothing new here. Someone claiming developing is
| possible only within the app domain is a fool.
| Veuxdo wrote:
| Very true. In fact, this was the impetus behind my project. Over
| the decades there's been a ton of focus on machine learning and
| big data, but virtual none on human understanding [of systems].
| bcbrown wrote:
| Relevant to this article is Peter Naur's paper on Programming as
| Theory building: https://pages.cs.wisc.edu/~remzi/Naur.pdf
|
| He argues that the biggest determinant on whether maintainers on
| a system they did not build will succeed is whether they will
| have access to the original developers: "The conclusion seems
| inescapable that at least with certain kinds of large programs,
| the continued adaptation, modification, and correction of errors
| in them, is essentially dependent on a certain kind of knowledge
| possessed by a certain group of programmers who are closely and
| continuously connected with them."
| cloogshicer wrote:
| That paper is amazing. Completely changed my view on
| programming. For those who find it a bit inaccessible (as I did
| on my first read), I wrote an article about it a while back,
| explaining it further and giving real-life examples:
|
| https://hiringengineersbook.com/post/autonomy/
| mikewarot wrote:
| >The main value of a software company is the mapping of
| source code and problem space in the developer's heads [In
| linked article]
|
| That is a profound conclusion to reach. For the most part, I
| think it's true.
|
| Without someone who wrote/fully understands source code, for
| example in abandoned software, the source code is a treasure
| map, the as-built plan of a building. It takes a lot of time
| and effort to orient yourself with things and make reasonable
| guesses as to what is going on. This aligns well with the
| original post.
| ilovecaching wrote:
| Nice article, I enjoyed reading it.
| cloogshicer wrote:
| Thanks! :-)
| MattGaiser wrote:
| A former colleague sent me an receipt that had an error from a
| system we worked on years ago (2 and 3 companies ago
| respectively). I bet we could tell the current devs where to
| find the bug pretty easily as we wrote a lot of that code.
| magicalhippo wrote:
| We see something similar with our customers. When our customers
| have some new projects or change their ERP or whatever, we
| almost always know better than they do how their systems and
| procedures work.
|
| Like, if they come with a change request we might ask what
| about X, they'll get all surprised saying no we don't do X, but
| after a bit of prodding sure enough, they discover they have a
| worker that's handling X every day.
|
| This is simply because we've been around, while they've had
| multiple new persons cycle through their departments. When they
| change the ERP system, we've still got the guy who coded the
| integrations with their previous system.
| wwweston wrote:
| 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 easy to communicate,
| rather than in conceptual forms that are easy to understand
| once communicated. Translation in the direction conceptual ->
| concrete and symbolic is much easier than translation in the
| reverse direction, and symbolic forms often replaces the
| conceptual forms of understanding. And mathematical conventions
| and taken-for-granted knowledge change, so older texts may
| become hard to understand.
|
| In short, mathematics only exists in a living community of
| mathematicians that spreads understanding and breaths life into
| ideas both old and new."
|
| https://mathoverflow.net/questions/43690/whats-a-mathematici...
| mooreds wrote:
| Haha, so true!
|
| I've found that for most systems, there are three great ways to
| "figure it out".
|
| * Start from input. (Browser, API, whatever starts a process.)
| Map from there.
|
| * Start from data storage. (Database, flat files, whatever.) How
| does state get persisted?
|
| * How does the system move into production? If you can make a
| small change (even adding an innocuous comment) and see it all
| the way from your machine to prod, you can iterate and start to
| map the system.
| samspenc wrote:
| 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 issue will
| be easier to fix. Don't roll out a fix before fully
| understanding an issue. As a corollary to this: always add a
| task to remove this verbose logging you added once the bug is
| fixed!
| bckr wrote:
| > 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.
| jollybean wrote:
| It's why good abstraction and documentation for it is so powerful
| - you only need to understand the API and not anything else.
|
| We start teaching about software like it's 'algorithms' when that
| is frankly, almost pedantic. That was never the hard part.
|
| Scaling the complexity was always the hard part.
|
| Simple, clear code, absent leaky abstractions, enough
| documentation etc..
| kache_ wrote:
| The problem with abstractions is that it seems that not making
| leaky abstractions is difficult for most people (most people
| making these abstractions don't know about the concept of an
| abstraction leakage in the first place)
|
| Software engineering is extremely difficult
| newaccount2021 wrote:
| Mizza wrote:
| 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..
| FractalHQ wrote:
| 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.
| twblalock wrote:
| The downside is those two lines of comments might be outdated
| and no longer match the code they purport to document, which
| can mislead you into believing something incorrect about how
| the code functions. I've seen that happen a lot.
| metamet wrote:
| Writing self documenting code alongside comments makes things
| so easy on people who have to understand your code later on.
|
| I have gotten quite a few comments from former co-workers who
| have taken over some of the projects I was lead on about how
| easy it was to read. That brings me a lot of joy, knowing
| that I made their lives easier and that the output of the
| trade I invest so much time and energy into is appreciated by
| my peers.
| bckr wrote:
| Great work creating value for your coworkers.
|
| That said, I think `self-documenting code` is the bare
| minimum in 2022.
|
| At my current role, I'm pushing the org to become
| "documentation first"--but this goes way outside the scope
| of writing code.
|
| It's about writing all 4 types of documentation[] as a
| daily practice. This way, when you create something or
| learn something, that gets documented for the next person.
| It's not just about what variables and functions are for.
|
| It's about what the business is doing and how that relates
| to our work, what our poor backend-cum-devops folks are
| having to do day in and day out, and about helping everyone
| accomplish their tasks without needing to go around getting
| help from 3 different people over 5 days because the system
| is completely opaque.
|
| [] https://documentation.divio.com/
| sjburt wrote:
| I feel like if there's good documentation, you don't need me.
| Similarly, the best leverage I can have is improving
| documentation or making documentation unnecessary through
| better interfaces.
| mooreds wrote:
| > Similarly, the best leverage I can have is improving
| documentation or making documentation unnecessary through
| better interfaces.
|
| I used to be a big fan of doco and still am. But a founder
| once told me that it is better to have intuitive UX (which
| obviates the need for documentation) and that rang true.
| FractalHQ wrote:
| I've always been fascinated by the glamorous toolkit project.
| Their ambitions are fascinating and align closely with software
| I've daydreamed about on more than one occasion. I wish I was
| more comfortable with lisp, or that it was compatible with
| Svelte/Typescript/Deno/Tauri which account for 90% of the
| projects I work on. I hope projects like this and Enso[0] are
| early iterations of what IDEs will look like in the future. There
| is so much room for innovation regarding ways to extend and
| augment the text formats used to author and represent software
| systems.
|
| [0]https://github.com/enso-org/enso
| leobg wrote:
| Thank you for pointing me to Enso. This looks amazing. For the
| others, here's a video demo: https://youtu.be/fQvWMoOjmQk
| nuancebydefault wrote:
| This matches my experience. IMO the best alternative tovreading
| code is to talk about the intent of the system by other coders or
| architects. Formulating questions is a start of understanding.
| Getting answers or directions increases understanding even more,
| for both parties.
| atum47 wrote:
| Yep, once I spent the whole day reading code to write one single
| line of code at the end of the day. Since my boss is also a
| developer he understands. Try to explain that to a manager who
| doesn't write code thou...
| giantg2 wrote:
| 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 between business and
| technical processes.
|
| But hey, that's just me. And it seems clear that most businesses
| do a poor job, or don't care at all, when it comes to documenting
| their processes. So I guess I'm the odd one.
| catmanjan wrote:
| Yes, and given its not documented there are bugs in the
| underling business process which end up getting encoded into
| the software...
| giantg2 wrote:
| Yes! And I love it when the business says they want to
| innovate, or improve efficiency, but they aren't willing to
| document and analyze the business process. Sure, we can
| implement your process as you communicate it to us, but I
| wouldn't call that innovative. Innovative would be modifying
| to process to take advantage of some new technology or model.
| stretchwithme wrote:
| You mean it's not like TV, where the code flows out of my
| fingertips for many lines and then magic happens?
| kingcharles wrote:
| No, it's exactly like that for me. Personally, I code
| everything in vertical lines of green hex on a black
| background.
| eldelshell wrote:
| println
| croo wrote:
| Isn't this the "hard part" of the job we are being paid for?
| mikewarot wrote:
| We're being paid to do the work necessary to meet the goals set
| by management, and to provide useful feedback and guidance
| about what is/isn't possible, and how long it will take.
|
| If they (management) choose to ignore our guidance, or straddle
| us with bad tools, it sucks for us, and them, and the company.
| indymike wrote:
| There are three ways you can make an app easy for new developers
| to quickly be productive in... as long as deployment and code
| management tools are easy:
|
| * Coaching/Mentoring - Original developers there to help
|
| * Great documentation - App is documented, and it's easy to
| discover how it's put together
|
| * Great API / abstraction - The api or structure is really easy
| to understand and use - this is why REST beat out more
| sophisticated API models. Even so, it needs great documentation
| to be easy to learn and build with
|
| I think a lot of companies don't get any one of the three above
| right, so everything is very opaque. Also, you _can 't let
| tooling_ block developers from getting into understanding the
| code. New dev onboard times are a great way to measure this.
| lizardactivist wrote:
| Using 3rd party software and libraries: spend hours flicking
| through documentation pages to find lots and lots of information,
| but no clarity.
| all2 wrote:
| For me, this activity is very often driven by "I need to do X,
| how do I do that?" It can be as general as "I want to make a
| web app with X language using Y framework". Often (for Golang
| and python, for example) there are lots of video tutorials
| talking about the necessary boilerplate -- so much boilerplate.
|
| It can also be extremely specific "I want to split a
| ReadOnlySpan<char> on some delimiter (which you can't do, you
| need to cast to a string and use the Split method there).
| Fortunately, that was an easy thing to find an answer for.
|
| Sometimes I want something specific that I have no clue how I
| would even start looking for the answer. I want to build a web
| app with a modular payment end-point so I can plug/play a large
| number of providers (ideally, I'd be able to arbitrarily hook
| in Stripe or the Bitcoin Lightning network or something else
| entirely). There are a host of problems for me here; I don't
| understand the problem space, so I have no clue what a "good"
| solution would look like, I don't even know if generic payment
| APIs even exist (zero research on my part), let alone in
| languages I understand (go, python, C#).
|
| I guess my issue is formulating questions appropriately, so
| that the sum of answers is an answer to my driving question
| "how do I do X?"
| davidw wrote:
| The older I get, the more important I think it is to get set up
| with a simple(ish) development environment where I can easily
| reproduce bugs, develop features and so on.
|
| This is one area where microservices can be a PITA if the dev
| environment hasn't had the same attention paid to it that the
| production environment has.
| sssilver wrote:
| Figuring out existing bespoke systems is what sucked the joy of
| programming out of my soul.
| falcolas wrote:
| 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".
| paulcole wrote:
| 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!
| [deleted]
| azinman2 wrote:
| I almost took a different path for my PhD and made it about
| capturing the knowledge that went into the creation of software.
| Can we see what people worked on, what they touched, how it came
| to be... in conjunction with the things they were also
| learning/consuming/reading/talking about so that we could bake
| that into IDEs. Right now we just see text files; the most we
| have is a git blame but you have to keep pulling the thread. It's
| also very hard to traverse across blames in time. I'd rather use
| past knowledge to both know what's related to some part, as well
| as how it came to be to determine where it should go next. I've
| always felt there's meat on this bone.
|
| The early days of Lighthouse IDE seemed to veer a bit into this
| by they since diverged.
| phyzix5761 wrote:
| This only has an impact when we want to change a system.
| Coincidentally, the majority of our work is changing a system
| through addition of new functionality or maintenance.
|
| I've thought about this problem for a long time. The conclusion
| I've come to is that it happens because the code doesn't look
| like the domain. Domain language is often missing in the code the
| engineers are working with so when new changes are requested the
| engineer needs to translate between the domain language and the
| language the code is using. I work in an object oriented language
| so my perspective is as follows:
|
| Ideally, all that should be required is a correct domain
| understanding. If the objects in the code reflect the domain as
| understood and explained by the people giving the requirements
| then the engineer's job becomes easier. Instead of solving 2
| problems, translation and engineering, they only need to focus on
| engineering.
|
| For example, imagine a payment system. A requirement comes in
| stating that the way a credit transaction is processed for a
| payment has changed. The transaction should now be processed by
| doing x, y, and z instead of a, b, and c. The engineer should be
| able to find an object in the code called a transaction with a
| method called process that takes a payment. Once they find this
| with a simple text search they know exactly where their change
| needs to happen. They should then see a, b, and c happening as
| explained in the domain language. Once this is identified the
| change can be performed.
|
| In reality, we seldom find domain objects with domain behavior in
| our code. What we find are Processor and Controller and Handler
| classes that have nothing to do with the domain. The behavior or
| data that we need to change is spread among multiple of these
| classes whose connection was decided by another engineer at a
| previous point. The new engineer has to work twice as hard to
| understand what decisions the previous engineer made to represent
| the domain.
|
| It's much easier at first to do this translation work because we
| don't want to, or have time to, understand the domain. But
| business domain experts are experts for a reason. They know how
| to solve business problems within their domain. We are not domain
| experts. So we end up reinventing the domain solution wheel when
| we do things this way. We end up solving the business problems
| and the engineering problems.
|
| Instead, we should see ourselves as modelers. Remember that
| computer science arose as a sub field of physics. The main
| purpose of physics is to develop models that represent the real
| world and solve problems using those models. Our job as software
| engineers is to model the domain and solve problems using those
| models. Our job is not to translate requirements into technical
| solutions. Nor is it to solve business problems.
___________________________________________________________________
(page generated 2022-03-30 23:00 UTC)