Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Developers spend most of their time figuring the system out

lepiter.io

Post reply on HN
Print view View original

201–210 of 418 posts

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

#201

Post by spywaregorilla »

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…

Possibly dumb question, but... why do orgs need specific pair programming policies at all. Why can't you just ask questions and help each other as needed?

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

#202

Post by bckr »

mikewarot wrote: post #42
croo wrote: post #9

Isn't this the "hard part" of the job we are being paid for?

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.

Also, "the hard part" is understanding the system--therefore, shouldn't we optimize that part to make it less hard?

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

#203

Post by ggregoire »

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

I 100% agree that code should be self-documenting. I sometimes create intermediary variables or extract 1-2 lines of code into functions just so that the code can be understood just by reading the names of the variables and functions.

But there is also information that you can't just describe into the code. There are the examples I already gave above. Another one could be what I did this afternoon: I had 2 options to solve a problem, I chose the more complicated one but the one that works in every case. I added a 4 lines comment describing the second option and why I didn't use it. There is no other way to add this information that would be useful for me or another developer in the future other than a comment.

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

#205

Post by bobkazamakis »

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…

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

Oh my! People complaining about things that are relative to the situation they are in! How fragile!

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

#206

Post by jollybean »

kache_ wrote: post #101
jollybean wrote: post #6

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

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

That they don't even teach 'leaky abstractions' is a bit rich, and as you point out it's hard.

And it's not 'hard for most people' it's hard for everyone.

Every API is leaky and inconsistent, it's all a matter of degrees.

Concise documentation is essential. I'm reading about a Java API for the 5th time and only now just 'getting it' fairy clearly, it's not rocket science it just needs to be explained properly. Java 'Direct Memory Byte Buffers'. Simple concept, described poorly!

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

#207

Post by Stratoscope »

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

Wow. I recommend everyone read through that page. Some may love it. Obviously the bosses at SOCi do. For me it is a dystopian nightmare.

To summarize: there are three roles, Typist, Navigator, and Support.

The Typist is not allowed to think. They are explicitly described as a "smart input device". For the most part, only the Navigator is allowed to think. They tell the Typist exactly what to type, and the Typist must follow everything the Navigator speaks, to the letter.

The Support only looks over both their shoulders and sets a 10 minute timer after which the roles rotate. Yes, every 10 minutes everyone switches roles.

When working in person, one thing this selects for is people with perfect vision. Elderly programmers need not apply!

Why do I say that? Well, I have computer glasses that let me see my screen perfectly even at my age. This applies to anyone over 40-50: if you don't have them already, I strongly recommend getting a pair of single vision prescription lenses tuned for your normal distance from the screen. Since I use a laptop, these glasses are set for a 20" focus distance. I have two external monitors (one landscape above the laptop, the other in portrait mode to one side), and I keep those at the same 20" distance from my eyes. It is glorious! Everything is in focus, all the time.

If we're sitting around a desk, it's almost certain that I won't be able to read what's on your screen, for the simple reason that it won't be at a distance that brings it into focus (probably much too far away).

Oh, and you may like dark themes and tiny fonts like all the young people use these days. So even if it were at the right distance I wouldn't be able to read what's on the screen.

Mobbing on a Zoom call mitigates the focus distance, but the dark theme and tiny fonts would still mean I can't see your code.

And webcams are supposed to be on all the time so your fellow mobsters can see your face. A nice sentiment, but two problems:

1. I can't work sitting. If I do, I fall asleep after a while.

2. I can work standing, but not standing still! (I'm no John Carmack, who can give an hour long talk without moving a muscle.) I have to move around in order to think and stay alive. So I would constantly be walking in and out of camera range, or stretching, or wiggling around on my Fluidstance balance board, or just looking out the window for a vision break.

A more delicate problem: Sometimes older people need to take more frequent bathroom breaks, and the timing may be unpredictable, especially for someone like me who eats a lot of fiber for intestinal health. Sorry, I may not be able to just "hold it" until the next scheduled mob break. (Apologies for the TMI.)

This whole thing is an ADA compliance lawsuit just waiting to happen. (And no, I'm not going to be the test case; I have no interest in working for a company with these practices.)

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

#208

Post by tharkun__ »

kevin_thibedeau wrote: post #68
Gravityloss wrote: post #61

Earlier quoted context omitted.

Text is linear. Would drawing be an easier method for you to explain something? It often is for me.

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.

I've found the opposite. An approximate quick and dirty visual representation can transport almost instantly the knowledge that writing back and forth for half an hour could never achieve.

When I learn about and talk about a system a visual representation of the flows of data and function calls is playing in my head. I get an overview of the system and what it does. Think "mental model". I "see" that this service calls that service to get that piece of data, which it gets from that database table and it all flows over there to do that and suddenly it all makes sense. I recall those high level flows for a very long time too and I have no idea how I do it. It just happens. I hope my mind keeps doing this for a very long time still.

I can talk about it and it makes perfect sense to me. There are other people at the company usually that share the same knowledge and understanding and if we speak a similar enough language we can communicate well. And then there are people that do not seem to get this level of understanding, even after prolonged periods of working on the same code base. Ever. When you ask them to explain to you how the systems and modules interact, they can't.

And then you draw some simple graphs of this service and that service, and this database here etc. and it finally clicks for them. They could not synthesize this from code or written text. They only ever saw the local view of the module they worked in. Overall, more abstract flow of information and modules was lost to them. You have to actually visualize it for them.

Note that I am not talking about "visual programming" as in drawing UML like diagrams and such to actually program. It's purely about showing data flow and call stack and such. Usually I don't need to draw this for myself as my head does it for me and it works really well with statically typed languages without any magic going on where I can just have the IDE navigate to exactly the right places, find all the code references quickly and accurately etc. One time (a looong time ago) I actually threw together a quick script to generate a graphviz file for the call graph of some system based on some proprietary database's stored procedures that I had to quickly come up to speed with and that nobody was there to explain to me. I think it printed out to like 15 pages that I taped up on the wall next to me just to make sense of it. No IDE support to click through from one procedure to the other.

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

#209

Post by bear8642 »

Gravityloss wrote: post #121
kevin_thibedeau wrote: post #68

Earlier quoted context omitted.

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.

We're not talking about programming here but explaining a concept.

Indeed! And even then drawing can help with the programming!

Discussing code for linked lists for example, having the box and pointer notation for what happens and scenarios very helpful!

[1][2][3] to [1][3] means changing [1]'s and [3]'s pointers and freeing [2]

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

#210

Post by hn_throwaway_99 »

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 by reading all of the old business requirements before trying to understand the code.

3. Even if the business requirements were documented perfectly, I rarely find that they are the major issue with understanding a code base.

Post reply on HN