Live data from Hacker News

Developers spend most of their time figuring the system out

lepiter.io

401–410 of 418 posts

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

#401
post #183

Earlier quoted context omitted.

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

Agreed that the amount of knowledge that gets systematized into papers, textbooks, and courses is a small subset of the total knowledge in a field, which is largely contained in brains. Although regarding your specific example: I believe the current most popular hypothesis about Fermat's Last Theorem is that he did not actually have a proof; it's very likely the proof he thought he had contained errors.

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

#402

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…

I've worked blue collar jobs. I've sold cars. I was in the infantry. I still hate listening to someone eat in close proximity, smelling their food and farts and all the other things people do in the office.

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

#403
post #104

Earlier quoted context omitted.

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?

Right, I'm sure they'll be up to speed within minutes and your business will suffer no delays or impacts!

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

#404

Earlier quoted context omitted.

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

> If your code is sufficiently clear there will be nothing left to say in the comments

Incorrect. The code can never tell you WHY. That's what comments are for.

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

#405
post #56

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.

The "Rails Way" doesn't work at all, and in fact hinders understanding, when a new developer doesn't know the Rails conventions. If you're happy to exist and hire within one ecosystem that can be fine. Otherwise it's disastrous.

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

#406

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.

The environment aims to make systems easier to grasp for people that want to explore their inside. This is quite different from the marketing challenge of convincing one to download a tool after a few seconds :).

If this was say, an optimizing compiler, I wouldn't worry that much about their pitch.

The tool is (from what little I could glean) supposed to make discoverability better. That suggests to me that they know something about how to make things discoverable, by bubbling up important information, hinting at where you want to go. The website was pretty much NOT that. Sure, maybe it's one of those "the shoemaker has the worst shoes" things. I'm interested, but not interested enough to work hard at figuring out what the thing is even supposed to to. If I want to work hard to explore the inside of a system, I can already do that.

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

#407

Earlier quoted context omitted.

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

a vs code live share would solve a lot of those vision issues.

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

#409

Of course, for this to be practical, the cost of creating custom tools must be small. The doubtfulness of that axiom is why writing code that is easy to read and understand without special tools is so important.

The creation of tools can actually be minutes cheap. Through Moldable Development one creates such tools regularly, and most of these are thrown away after being used just once. That can sound like a waste, but it's a significant booster. It does require new skills though.

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

#410
post #56

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.

The "Rails Way" doesn't work at all, and in fact hinders understanding, when a new developer doesn't know the Rails conventions. If you're happy to exist and hire within one ecosystem that can be fine. Otherwise it's disastrous.

The alternative is living in a microcosm of your own product/company, as the rest of the world is the wild west with no purported conventions at all. So even if it's a disaster, it's a better disaster than not having recognizable conventions that anyone outside of your company is aware of.

And I say this as someone who originally live-edited PHP sites over FTP on apache in the early 00s. Convention is everything.

Rails can be quite a disaster, but it has some solid conventions on app structure, routing, and security. It's not that Rails is great, it's that having conventions and sane defaults that get you somewhere instead of nowhere is better than not having them. No other major popular framework that I'm aware of has any real conventions on app structure or on any of the core things that 99% of apps need anyway, so everyone is out there re-inventing the wheel.

In most frameworks, you get almost nothing included by default, and have to make key decisions on things like how will you encrypt cookies, how will you do CSRF protection, and sometimes even more basic things like how will you do routing. This has led to rampant security vulnerabilities reminiscent of the PHP days of yore imo. Productivity-wise this has made it impossible to get anything done, because the second you go to work for a new company, you end up having to help them re-implement basic processes like integration testing, CI, app structure, because everyone in the wild is just flying by the seat of their pants and making it up based on their limited experience and knowledge. "Oh, we just copy paste this boiler-plate and manually load SQL files for our migration system" "What's CSRF?" "What do you mean having separate environments for development, testing, staging, and production?" "Oh, we kept getting that CORS error so we just added a wildcard and it went away" etc etc

Post reply on HN