Ask HN: What do you wish more programmers cared about? | Hacker News Reader

Ask HN: What do you wish more programmers cared about?

16 pointstopaztee29 comments

Code dependencies, and how dangerous they can be.

The art of writing code that doesn't build on top of a jenga tower of shit has been lost. It turns every software engineer into a code monkey that, instead of crafting good code, is simply trying to keep the jenga tower from collapsing. Yes, it's faster when getting an MVP up and running, but the quality of apps (and their speed) has gone down drastically over the last 10 years.

...to the point where I no longer enjoy software development, and am actively trying to quit the field.

Do you have any advice to more novice developers on how to be less “dependent” on dependencies? Where can we learn the lost art of writing code?

It feels that unless you want to reinvent the wheel, you need a bunch of third party libraries to get anywhere near results clients want within ecosystems like JS/Python.

Feeling somewhat same, consuming some libraries and placing the code at right place, not that its bad but not really doing problem solving apart from writing conventional business logic in code

Operating system security. The consensus seems to be that Users, Hackers, and Microsoft are responsible for the current crisis in "cyber security". Any mention of the need for a better underlying security model, such as capabilities, is dismissed as quickly as possible.

In the past, our hardware was too dumb, and we didn't have persistent networking, so we could get away with things that are obviously stupid in today's context.

No current OS can be made secure, and remain usable. It doesn't have to be this way. We can have safe and secure general purpose computing. If we don't push in that direction, the government is going to regulate things down to the bit level, and it still won't be safe.

Any idea on organizations working on this or ways to get involved?

My main way of helping right now is to keep pushing awareness of capability based security. If people don't know something is possible, they don't reach for it as a solution to problems.

Genode seems to be the closest to general use, followed closely by Google's Fuchsia.

Simplicity. There are absurd numbers of overengineered BS tech just because someone needed to put it on a CV or were just measuring dicks. There's also tons of extremely useful software that has zero design thinking in it, therefore even though the features are great, the usability isn't..

The context of what they are developing. I've been in teams where I seemed to have genuinely surprised people when suggesting to talk to the actual users and asking for some feedback on what for and how they are using the tools we developed (vs what the product owner thinks), or to have a chat with developers from "next door" teams.

Learning how things work, not just how to use them. You don't have to know in ins and outs of a compiler, but you should probably understand the structure of how Django works so you know what's going wrong when you're getting an error instead of blindly copy and pasting to google without even reading the error.

The craft of coding and pride in their work. Over the last 12 years I have worked with more people than not that hand off code that solves the problem, but is sloppy and not very readable. I've wondered if this is a byproduct of rushing to meet sprint deadlines.

Learning to do proper debugging. Again, 3 orgs in 12 years, and it seems like the debugging skills of those coming into the industry are getting worse. Personal observation, so take it for what it is, but it seems like even developers 2 or 3 years into the industry still don't know how to use debugging tools or have a "system" for troubleshooting and investigating an issue.

I think my debugging skills are not that good, as i have recently started working with peers and i notice that i go blank on how to proceed to tackle some problems, i directly go to google thinking of getting solutions to same, as i fear i won't be able to deliver the task on time, how to improve writing good code and debugging, some say practice, but even with practice i feel someone else comes up with better approach than me while writing better code, i feel very inferior about it.

Literate programming. This is an idea that keeps being reinvented.

The names I have seen are:

Readme driven development. Documentation driven development. Executable documentation. And many more..

This is the way. Sadly, it never took off.

DDD is another great approach that never entered mainstream.

Leaning harder to use better programming languages and tools. So many devs I know would much rather be using something else, but just go along with using whatever is popular.

This takes effort in both convincing and in putting in the extra work to make it work smoothly because it isn't a beaten path, but if the choice isn't superficial it will more than pay for itself.

Even when you don't dictate the specific language used, you can still strongly influence the style of program composition so that it has less mutable state or distantly-coupled behaviour and the like so that it works like a better language than if you didn't.

Working in legacy code

Legacy code (ie any code users actually use ;) ) is the life and blood of actual value delivery. Warts and all... your life in legacy code is truly navigating the dance between paying off technical debt and delivering new features in a codebase currently serving a userbase. Doing that dance is hard, but fun and rewarding.

Legacy code is crystalized knowledge of a problem domain.

Legacy code is Chesteron's fence. It is wise to understand the conditions that caused it to be built before changing it.

Which is why Feathers’ book on the topic spends so much time on testing. Establishing a test suite that allows you to (hopefully) make changes without breaking things, and if you do you find out quickly.

about their own mental and physical health. Essentially it's the only thing that matters in the long run.

Working on environmental issues. That includes myself. It's tough though, the companies I talked last job cycle don't seem to pay anywhere near well as other companies and didn't seem like great companies to work for (benefits, culture, beaurocracy) when interviewing with them.

What their code could actually be used for.

I was so surprised when a really talented dev at my company went to Facebook because of their solid perks. I mean, I get it, but at the same time this person seemingly gave no thought to how evil their new company was.

Being good at making clear, useful and simple abstractions.

Although not the only way being good at this, mathematical thinking helps. What information can I discard, what's important, what isn't important?

The problem is you can get them so badly wrong.

Well maintained documentation, specs, the state of the project.

It’s tough to have to dig through a legacy project to figure out its state, what it does versus what the docs say it should do.

The human element, or design and UX/UI & ergonomics. Don't code for 'the developer', code for your users.

As a user, security and user freedom of course.

Dependency hell

Ops

+1 - specifically, not undermining/cutting corners wherever possible at the expense of the system’s health

Each other

freedoms

Reply on news.ycombinator.com