Hacker News Reader

> No enforced values by one or another interest group.

I wish. Try working at almost any company, and you'll have to betray your users on an unrealistic arbitrary deadline.

The industry doesn't appreciate people who think, or talented people, or good engineers. It appreciates those who can haphazardly slap together a subpar something out of ready-made libraries to meet "business goals". And this is depressing af.

I've been using the phrase "Dung-beetle programming" for that dominant mode for some time.

I love that!

I am a "dependency skeptic." A lot of folks think I'm against them, but nothing could be further from the truth. Most of my software is composed of dependent modules.

Mostly written by me.

I don't oppose the whole concept of using libraries. I just look closely at each library I'm about to include in my project to understand what exactly it's doing, what it's abstracting away, what are the tradeoffs I'm making, and whether its scope is too broad for whatever I'm trying to achieve. It's sincerely perplexing to me that not everyone does this.

The other biggie is legal and fiduciary exposure. That's usually neglected by tecchies.

You can't ask a lawyer, because they will always say "no," but I have seen some really bad things happen, because people didn't take this stuff seriously.

I never take this stuff seriously, but then I never really worked, or ever had the desire to work, on anything this proprietary, or in a company this bureaucratic. When my first employer was acquired by a giant corporation and I started seeing it transform into this monstrosity, I quit.

The problem can be when something untoward happens with a dependency, or a buried dependency, like a security breach, or a licensing issue.

Lawyers will generally chew up the food chain, and applications that use dependencies can get caught in the blast radius.

That can happen with big shops, or small shops.

Anyway, I've never in my life consulted a lawyer about my or someone else's code. The whole idea feels weird.

I will bet you don’t live in the US.

Around here, lawyers are a dime a dozen.

I don't. I'm Russian.

> It appreciates those who can haphazardly slap together a subpar something out of ready-made libraries to meet "business goals". And this is depressing af.

OTOH, those who can do this while still maintaining some integrity get a lot of respect, at least in communities like HN. I'm reminded of Spolsky's "smart and gets things done."

And just to push back a bit: reuse is a good thing. Indeed, by looking first to make sure you aren't re-implementing the wheel, much of the spurious software that this article bemoans can be avoided. I know it sounds like an imperfect compromise, but that's because it is. Sometimes you just need to get shit done.

Dependencies are great. It's how small teams do big stuff.

Dependencies are awful, it's where jurassic-scale disasters are born.

Whether we like it or not, dependencies are here to stay. It's like calculators are now an integral part of every student's book bag. I'm old enough to remember when you would get thrown out of school for bringing a calculator.

It's just that when we develop and publish infrastructure, it needs to be held to a much higher standard than the apps that are built on top of it, and I'm not sure we're at the point where we can implicitly trust infrastructure. Being good at vetting and choosing dependencies is still an extremely valuable skill.

It's using dependencies without understanding them which is apparently the norm these days, and this really grinds my gears.

> I love that there are so few limits in "software world." No pesky laws of physics.

Actually...

Laws of physics are very important to software engineering. Stuff like speed of light and ability to disperse heat have a tremendous influence on how computation can and is done, and how we design software systems.

Then there are laws entropy and complexity, math laws & cryptography, social laws (how do people cooperate), game theory, economic laws and legal laws. And bunch of other stuff that I forgot about now. All greatly limiting / shaping the way we can create software at scale.

Software engineering is one of the most (if not the most) complex forms of engineering out there. A lot of people don't realize it, since they routinely work with tiny parts of the whole picture. Writing a typical REST API backend, or making a RPi blink an LED is like civic engineer building a popsicle stick bridge. Sure it's fun, but that's not "the whole field".

I suspect that most engineers do not regularly come into contact with the laws of physics, or it's dressed up as "xyz is too slow".

Software development is a field with a lot of breadth and depth, and a lot of engineers do not regularly come into contact with things that are "far away" from them.

The other day I saw a comment on a forum about a videogame saying something along the lines of "an experienced programmer would wonder why there are two different compilers at work here".

The industry has expanded enough that we can have people with a decent amount of time spent programming without ever encountering things that other people with the same amount of time consider normal.

Importantly, it's vital people don't look down on engineers which don't work at the very lowest levels of abstraction. There is quite a lot of value gleaned from abstracting the electrons away.

> Actually...

> Laws of physics are very important to software engineering.

there are practical concerns abound, especially if you're going to focused as you have on on industrialized software production.

but to me the defining nature of computing & the digital is that it is very near to unlimited, that it is about how we think, what abstractions we create, out of vast vast vast potential & endless capabilities.

yes there are some limits. but growing up, I wanted to build boats & houses & submarines & planes. much of the attraction of digital technology was a near into complete freedom from physical constraint. the 486 I had was a machine with infinite potential, something I could put myself into endlessly, ever becoming more, ever imagineering further frontiers to build & advance into, & everyone else could do the same, & we might still never cross paths. computers are an "unmaterial" wonder, something wholly unlike all else.

I implore us to think not just of the limits, laws, but of the endless spaces the mind might be free to travel & explore amid the digital.

I've never worried about the state of software because I've never believed it will solve all of our problems, and I've developed hobbies and an identity outside of my career. If software causes you existential angst, it's a sign that you're putting too many eggs in one basket.

Software isn't perfect, there are perverse incentives, and everything gets messed up -- because it's a human endeavor, just like everything else.

But I enjoy it and it pays well. I try to point the ship in the right direction when I can.

What prevents one from using this argument with everything? In a sense, I don't disagree, but what sets apart active recognition and embrace of the limitations of an endeavor, and passive resignation to the shortcomings of circumstance, which smells more of indifference from a fatal desire for sleep and forgetfulness?

I believe the answer to that question is simpler than most would think. To untangle competing desires and figure out what you really want, you have to cultivate more awareness. Listen to your feelings and your soul.

You might determine that you've been working too much, fighting battles unfruitfully, while neglecting the things in life you actually care about, like family. Or you could decide that software really is your way to contribute to the world, and find a way to optimize for that.

Either answer is fine. Either way, if you figure out what you ACTUALLY want instead of what society tells you, you'll be happier and find more purpose.

There are no answers in life. Just strategies. Find out what you actually want, and find the most effective strategy.

I like that.

In my case, I love designing and writing software. It's my hobby. In particular, architecting software, in a fashion that is "organic." My architectures morph throughout a project.

If you look at my GH repo[0], you'll see that it's solid green. I don't really take weekends off. In fact, I often get more done, over the weekend, than I do during the week.

What I can't stand, is the "baggage" attached by folks that don't love developing software as much as I do. Team dynamics add overhead, but that is not necessarily a problem. Insecure managers or team leaders, on the other hand...

[0] https://github.com/ChrisMarshallNY#github-stuff

“Put all your eggs in the one basket and — WATCH THAT BASKET.”

- Mark Twain, from Pudd’nhead Wilson

That's the teaser quote I use for this story: https://littlegreenviper.com/miscellany/testing-harness-vs-u...

> there are so few limits in "software world." No pesky laws of physics.

Computability theory has a similar flavour, though. There are hard rules about certain things not being possible.

Thermodynamics and computability are pretty directly related, actually

Can you say more? Is there a thermodynamic interpretation of, say, the Halting problem? (Or P vs. NP?)

The answer to your question is not straightforward, but it is not a definite "no". Here is an interesting (albeit amateur) discussion on the subject on Stack Exchange: https://cs.stackexchange.com/questions/26049/is-there-a-conn...

This is in relation to the ‘say more’ part, not specifically about the halting problem or P/NP.

Since computation is physical, there are theoretical bounds on the energy consumption of computation. (Landauer’s principle [0]).

Physical limits computation are at least one way to think about the relationship between thermodynamics and software.

[0] https://en.m.wikipedia.org/wiki/Landauer%27s_principle

What you wrote reminded me of this ('Why is programming fun?' from The Mythical Man-Month, by Fred Brooks): http://grok2.com/progfun.html

> no pesky laws of physics

To be fair we still are bound by mathematics - boolean algebra, graph theory, information theory, etc. N=NP comes to mind

I used to have an employee that is a physicist. He would get bent out of shape, when I said that. :)

Pretty sure at this point code also obeys the lows of Thermodynamics

That’s right, the entropy grows for sure. (Code also takes up any volume given to it.)

N, NP doesnt matter. Most likely O(n^100) is too large for any sizeable n.

Let's not forget the speed of light (latency) either.

> No pesky laws of physics.

Unfortunately many software projects seem to be limited more by pesky psychology, and while natural laws are reasonably universal and consistent, the diversityof human insanity/stupidity is incredible

I wish the industry was art/craft oriented. I cannot count the amount of wounds I got due to the business mindset.

Ever get an out of memory error? There go those “pesky laws of physics”! Otherwise great points about the craft of writing software — what we need is a better apprenticeship system.

> No pesky laws of physics.

While developing on a single host (especially in traditional imperative and object-oriented languages) papers over a lot of fundamental physics. The nonexistence of absolute simultaneity and the derivative concept of data gravity are very much a thing in even the most basic contemporary software systems... The most ubiquitous system to deal with it, is I would say, the "Virtual DOM".

What's data gravity?

it's the concept that data are difficult to move and attract the code to it. Generally used, in the large to describe things like AWS S3 attracting AWS to build services on top of it. But I think it's true in the small, too like "frameworks on top of each person's browser data".

"Data gravity is a metaphor introduced into the IT lexicon by a software engineer named Dave McCrory in a 2010 blog post. The idea is that data and applications are attracted to each other, similar to the attraction between objects that is explained by the Law of Gravity. In the current Enterprise Data Analytics context, as datasets grow larger and larger, they become harder and harder to move. So, the data stays put. It’s the gravity — and other things that are attracted to the data, like applications and processing power — that moves to where the data resides."

https://www.cio.com/article/3331604/data-gravity-and-what-it...

What's a virtual dom? Some sort of socially-distanced BDSM scene? What does it have to do with imperative programming and object-oriented languages?

Probably taken from: https://reactjs.org/docs/faq-internals.html#:~:text=The%20vi....

Tl;dr It's a representation of the Document Object Model in JavaScript/application land. Changes are made to it before updating the actual DOM, because real updates will cause reflows, repaints and other expensive operations that can slow down the page.

No idea what that has to do with anything else GP said though.

Can you explain how a virtual DOM solves what you're talking about? Seems to be a non sequitur to me.

There's all sorts of separate sources of truth in that system: Data that exists in the server, data that exists in your javascript frontend, data that exists as pixel intensities in the screet. At a high level, the virtual DOM exists to arbitrate the non-simultaneity of updates to all of these moving parts. It lets react model its system as a "single source of truth" with a functional "prop-drilling system". It gives react components gravity to a data source it can consider authoritative (separate from the actual DOM which attracts the browser's own sets of sub-applications) which is also separate from the applications sitting on top of your data in the server, etc. etc. etc.

>I love that there are so few limits in "software world."

I'd love to visit that world you live in. Software development is nothing but a huge heap of trade-offs based on limitation of all kinds. Money, time, quality, re usability, maintainability, and many more. I'm ready to bet there is no other job out there that is as complex and bound by so many parameters than software development. Maybe hardware development but I put them into the same category personally.

>No pesky laws of physics.

Try low level programming or high performance software. Your worldview will change very quickly. Not everything is fluffy javascript ;)

>No enforced values by one or another interest group.

I'm at a loss of words. Software is what makes the modern world move. You literally cannot avoid interest groups that want to influence you once you have a popular software that is used by millions.

Sure you can write some hobby projects and avoid all of the above mentioned, but once you do something with impact that is used extensively to help people (something everyone should strive for!), all of those issues WILL come to haunt you. No exception!

> I'd love to know what world you live in. Software development is nothing but a huge heap of limiting trade-offs based on limitation of all kinds. Money, time, quality, reusability, maintainability, and many more. I'm ready to bet there is no other job out there that is as complex and bound by so many parameters than software development. Maybe hardware development but I put them into the same category personally.

Theoretical physics?

Car manufacturing?

Rocket building?

Some other forms of engineering?

Just brainstorming, I have no clue. What do you think?

Now, be nice.

I live in a very, very real world. I suspect that it may even be the same world that you live in.

It was really a rhetorical exercise. Of course there's all kinds of constraints and whatnot, but, in my case, I started as an EE, working at a company that made fairly advanced microwave equipment, and, there, the laws of physics made it quite difficult to do what we wanted.

Software was like walking out of a tunnel, into a sunlit field. I could go in any direction I wanted.

It really is quite amusing how we like to sling aspersions at each other. I'm not here to compete with anyone. In fact, I find the fact that so many people are so much better at stuff than I am, to be quite comforting.

I love learning.

> but once you do something with impact that is used extensively to help people

You have no idea...

If you would've lead in with your background I might have been more careful ;) Just rubbed me the wrong way the way you wrote it, so i wrote my response in a similar manner.

Good software is equally intricate and complex as many other fields that superficially seem more complex, like Rocket Surgery. Unfortunately it has changed a lot over the last 20 years. Just learn to use these libraries, go to a bootcamp and call yourself fullstack developer.

Few people even know what instructions per second even means. Deliver 300MB chat applications or 40GB Games to your customers and call it a day.

Good software development is more than an art or craft, it is seriously hard and takes a lot of experience and it is NOT relaxing at all. It is rare, unfortunately and it's just frustrating to see the decline over the last 20 years.

Point taken. I am used to being around folks that know my deal, and am sometimes too casual in my interactions.

I suspect that we'd probably get along, IRL. I got a gander at your site, and it seems that we have a hardware interaction background.

I'm deliberately trying to reduce my scope. I worked for many years in a fairly major-league Japanese corporation, as part of a big, distributed team. The company was a hardware company, so a lot of our software was designed to either play with, or be embedded in, hardware.

Nowadays, I like to try keeping it to apps for Apple devices. My apps tend to be a fair bit more ambitious than you'd normally see from a one-man shop, but they are still fairly humble, compared to what our teams worked on.

However, I feel that the quality of what I do is better than before; mostly because of my craftsman approach. If you knew the company I worked for, you'd find that ironic.

> once you do something with impact that is used extensively to help people (something everyone should strive for!)

Why should everyone strive for this? It seems unrealistic at best.