> Taxes exist to fund the government which exists to solve collective action problems.

Wealth inequality, billionaires trying to skew politics… kind of a problem that needs collective action.

I think it is excellent as well—that it also demonstrates aperture and shutter priority is a bonus.

I do feel (image nerding now) that its shutter/ISO visual for showing the image over/under-exposed is not quite correct. It appears they show incorrect exposure by taking the "correct" image and blend (multiply) with either white or blend with black (on the other end of the exposure spectrum) to produce the resulting image.

I suppose I am expecting something more like "levels" that pushes all the pixels to white (or black) until they are forced to clip. (But maybe I am too trained in photo-editing tools and expect the film to behave in the same way.)

No, you're correct. I would have expected the highlights to blow out much sooner (for digital) and the shadows to block up much sooner (for analogue). The simulation doesn't portray this accurately, but it gives the general idea!

I'm 61 (retired when I was 57).

I too began with BASIC (but closer to 1980). Although I wrote and published games for the Macintosh for a number of years as I finished up college, my professional career (in the traditional sense) began when I was hired by Apple in 1995 and relocated to the Bay Area.

Yeah, what started out as a great just got worse and worse as time went on.

I suspect though that to a large degree this reflects both the growing complexity of the OS over that time as well as the importance of software in general as it became more critical to people's lives.

Already, even in 1984 when it was first introduced, the Mac had a rich graphics library you would not want to have to implement yourself. (Although famously of course a few apps like Photoshop nonetheless did just that—leaning on the Mac simply for a final call to CopyBits() to display pixels from Adobe's buffer to the screen.)

You kind of have to accept abstraction when networking, multiple cores, multiple processes become integral to the machine. I guess I always understood that and did not feel too put out by it. If anything a good framework was somewhat of a relief—someone else's problem, ha ha. (And truly a beautiful API is just that: a beautiful thing. I enjoy working well constructed frameworks.)

But the latter issue, the increasing dominance of software on our lives is what I think contributed more to poisoning the well. Letting the inmates run the asylum more or less describes the way engineering worked when I began at Apple in 1995. We loved it that way. (Say what you want about that kind of bottom-up culture of that era, but our "users" were generally nerds just like us—we knew, or thought we knew anyway, better than marketing what the customer wanted and we pursued it.)

Agile development, unit tests, code reviews… all these weird things began to creep in and get in the way of coding. Worse, they felt like busywork meant simply to give management a sense of control… or some metric for progress.

"What is our code coverage for unit test?" a manager might ask. "90%," comes the reply from engineering. "I want to see 95% coverage by next month," comes the marching orders. Whatever.

I confess I am happy to have now left that arena behind. I still code in my retirement but it's back to those cowboy-programmer days around this house.

Yee haw!

you also have bozo managers like my recent one measuring metrics like PR time open, review count

while the team hasn't shipped anything useful in 6 months.

Honest question — why don't managers like this get fired? My team wants us to ship fast. If I don't ship for a month I'm probably gonna lose my job, and rightly so.

If a whole team is spinning its wheels at the behest of its manager I feel like the manager should get axed.

Because if that's what they were told to do. The organization is likely very dysfunctional, or has messed up priorities, which is probably about 80%+ of the startups out there and companies in tech in general.

Seriously. There's not many healthy engineering organizations out there. So if you fire one manager you end up with either another bad one or one who performs poorly due to the organization.

Paramount here is culture. It's important to remove toxicity. I remove toxic managers (and team members) because even if they were smart or productive, they ultimately drag down the entire org and the net of it is negative productivity. I don't care if they were the most skilled programmer on the team. Doesn't matter. They could be unproductive or could be making others unproductive and unhappy. They're out. They're out before they burn or push someone else out.

So you may also find that is the reason. If the manager is generally a positive influence on morale or culture, but is perhaps just a little too reckless, they may still have value. Remember that the reckless pressure may even being coming from top down. A lot of people still subscribe to (and misunderstood) the whole "move fast and break things" mantra.

It depends, of course, but in my experience managers like this do get fired after a few years, followed shortly after or before by their manager.

Years! I can see why managerial positions can be so coveted. You can be shitty at your job for years before getting sacked.

It's easy to hide in those positions. Many people don't know how to measure performance there and they get to point fingers.

My advice to anyone in this boat is to talk to the team underneath them every now and then. Get a pulse check. See where they get stuck and then set the managers goals based on that. At least one of their goals. It can be a small thing. It need not derail any roadmap or anything else. Explain why it's important for their team, explain where the team is having trouble.

See if they do it. If they do, they care about their team. If it's a small task/goal, it proves they can also be productive. Often times we have people taking on enormous goals that are vague or difficult to measure or complete in a timely manner. So a little mini goal (or a few, test a few over time) is very important here. Now, if they can't meet this goal or are unwilling to - you know you have a manager that doesn't care about the team they are managing. They can't manage that team or they can't be at the org. You can of course always try a different team or role for them.

In my experience a lot of managers (especially middle managers) kinda like to sit up there in a tower shouting orders at people, but never want to get their hands dirty or never want to support their team. They sometimes don't even realize the orders they are shouting are incorrect or impossible tasks to complete. This is where you get the "you now need 95% test coverage." That very often doesn't come from a C-suite level or customer demand because they don't care what the % is, they just want it to work.

Because the managers of those managers don't know the difference.

typical management layer in big tech

manager < senior engineering manager < director of engineering < vp of engineering < cto

why are so many layers needed ?

it incentivizes busy work and shit metrics like I outlined above. if they fire the manager it also means their managers have to get fired too

it's like communist party bureaucracy just veiled with tech

cto is a very wide title and in a global enterprise with hundreds of thousands of employees it's impossible to have a flat organization. There's probably 15 vp of engineering reporting to the cto. Each vp is going to have 10-20 directors reporting to them and beneath directors the fanout gets even wider. It does incentivize busy work and in a large org you can hide in the corner and be a potted plant for your whole career if you're smart enough to find it. But that is the nature of a large cooperation, I can't remember who said it but something like 80% of impact and progress to keep a business going is made by 20% of employees whether it's a big company or not. The rest are just sort of there playing along.

Depends on size of org. Many orgs end up too top heavy too quickly and don't have things in place to support that. That's where you get the "busy work." It's because they have too much time on their hands.

Hey, I'm now measuring PR open time ... Only because there's been open PRs for months. It is of course possible that broad directional metrics are useful.

Its crazy how management has gone from productivity to a kind of policing, crowd control and abstract number management that has no sense.

One of things that's being discussed now is AI won't really help people ship products faster, because no one was serious about building them at the first place. In most large corps the managerial layers simply care about preserving their own jobs and comp.

Also similar things an be said about Product management too. Only a few months they would says developers are busy with other things, now that we can ship quite fast, whats your world changing idea? None

I like my manager but I think what many people don't seem to understand is that the manager tends to be the bottleneck. We were moving as fast as he was able to give requirements even without AI, and now we're being told to use as much AI as makes sense and now we just more product roadblocks faster. We may be shipping faster but amortized over all the roadblocks I'd say our velocity is like 10% faster.

Code was never the bottleneck.

Thanks for sharing! I definitely agree. I've seen web software go downhill somewhere after 2013. It's been sad and now we have far more buggy apps and security issues on the Internet than ever before.

I used to love the 90s because it was "for nerds." The space wasn't crowded and you could actually do good work and research. So much research went into things and I feel like that died somewhere. Or is dying. You get a few good things coming out here and there, but it's masked by this "I want to be a celebrity" stuff that's going on. It started with conferences and such and has now progressed to YouTube and live streaming. That's kinda sickening to me honestly. What we have is pull in directions from the loudest voices in the room despite the fact this pull could be directly into flames.

As people try to sift through the confusion and overcrowding they tend to grab on to anything they can for refuge. Ironically they are often unaware of the dangerous situation they put themselves in.

I think cowboy coding may see a definition change.

people twisting and manipulating llms to do all sorts of unintended things reminds me of the late 90s early 2000s when everyone was twisting and manipulating html, webservers, and browsers to do all sorts of unintended things. It kind of has that feel to me, where it's something new and no one knows where it's going but i seeing a lot of "hey check this out, i put this together last night and it's kind of cool" again.

At least AI seems very useful to quickly write unit tests for the stuff I work with these days, like Angular & C#.

P.S.: I loved Glider and Glypha, great games!

I don’t have anything to add other than to say this was beautifully written.

I’ve never been asked for coverage as a metric or target, at least not by managers. Most of the… drudge that you describe seems to come from fellow developers. These are self-inflicted wounds by the “journeyman idealists”, making us all perpetual beginners.

(That said, I do like unit tests and I think code reviews can be useful for sparing if you have a good vibe and trust in the team.)

I have seen coworkers, who are otherwise very nice people, become rather nasty when given some authority over other's code in the form of code reviews. The code review turns into "this is how I would have written it, rewrite it."

What we did before code reviews: we would get together with our fellow engineers in front of a whiteboard and knock out the structure of the code one was tasked with. We'd argue whether caching is necessary or if the framework provides it for us. We'd talk about concurrency issues and whether to use semaphores or locks…

Once the plan looked good, an engineer was trusted enough to go off and implement it.

Unit tests are fine. Before unit tests we had coworkers (QA) that did full test suites for integration, functional testing. At the more "unit level", robust param checking (with assertions, logging) happened early within the functions that could fail. (Obvious example: checking for zero in a function that might use that value to divide. Its a kind of unit test in situ.)

Of course when management uses unit tests as some kind of replacement for actual integration and functional testing they become an end unto themselves (bonus: the company is also able to lay off QA).

I understand. It’s a great reply.

To my dismay, I’ve never worked in a place like the first one you’ve described. Managers have certainly been confident enough in me to just let me ship stuff I built alone, or obviously that a team built without the usual red tape. Your model is very intriguing, I’ll try to implement something similar if I’m ever again able.

It’s true that code reviewers can become feral and the smallest detail a source of contention. I’ve had otherwise good team leads completely rewrite my code after accepting a review. It’s okay, maybe it wasn’t that good. Egos hurt and get hurt.

About QA: well, companies — I hope — eventually pay the price. Apple’s image of software quality now contrasted with a company that lost the trust of power users. QA and unit tests are complementary. If anything, it’s acceptance and integration tests that hurt QA, but I’ve never seen these 2 done properly anywhere.

I'm a millennial, but I share some feelings. I also think modern programming careers often feel like factory jobs where most of the time you must be compliant with some BS. You often find the true joy only in personal projects.

Modern programming careers _are_ factory jobs.

Until you have some sort of senior+ position you are literally just standing in front of a conveyor line.

> But the latter issue, the increasing dominance of software on our lives is what I think contributed more to poisoning the well. Letting the inmates run the asylum more or less describes the way engineering worked when I began at Apple in 1995. We loved it that way. (Say what you want about that kind of bottom-up culture of that era, but our "users" were generally nerds just like us—we knew, or thought we knew anyway, better than marketing what the customer wanted and we pursued it.)

That is why y'all needed the God-Emperor of Marketing to come in and rescue you from bankruptcy and put you on track to becoming a trillion-dollar company.

Growing up, my American-addled brain could not comprehend putting the "good of others" above my own empowerment. The focus on the individual (me, I suppose) was a thing I was, for some reason, proud of about the U.S. (or perhaps "the West" by extension?).

Only as an adult, with a wife, kids (and perhaps a better perspective of the world?) did I realize how foolish I was growing up. And I see more and more how we, as a nation, constantly pay the price for that mindset.

Naive self-interest is a characteristic of children. You didn't stumble upon some ancient wisdom of another culture, you just matured and established a family, which your instincts tell you to put before yourself.

The West is individualistic, but all that means is that individuals choose their circle of concern. Without any further guidance, that means that innate instincts about who is important (family, close friends) dominate, rather than a forced narrative about the collective.

Not the "West", obsessive single minded individualism is a US characteristic. All other western nations (read: Europe) realize that there is significant value to society and that to achieve things we need to work as a group.

> and that to achieve things we need to work as a group.

yeah, lots of "cooperation" in europe all right. left and right hate each other just as much as they do anywhere else

I think it has more to do with agency than age except that agency increases with age.

Look at prisoners, people dependent upon disability, people in authoritarian societies, you see all the same stuff. They're just more tactful about it because they're adults.

Kids do think about others and cooperate, they do have natural empathy and care too. A lot more in cooperative cultures where they are taught to be like that. Less in individualistic cultures where they are taught to not be empathetic. Even within West, there is range of individualism. Netherland is different then USA and both are different then Spain.

It is not just instinct that makes some people (including kids) dominant, it is also that they are being actively taught to act like that. The natural thing is for parents to teach kids own values, both in a planned and conscious way and in the "by the way" style.

I always heard that individualism is centric to the American mind, but on the other hand, I found that American interests groups (corporations especially) are very good at "hunting" in a group. I talked to some mid-level policy-maker friends in China and they recognize that the American corporations are very good at working as a "wolf pack", while the Chinese ones usually fight each other -- you can see examples in Huawei versus Zhongxing when both are competing in foreign markets.

However, complaints about this always ring hollow because it’s constantly tied to a political goal.

“Americans are so individualistic, they don’t care about climate change.”

For how many Americans don’t care about their credit score, or bank account, or student debt, or local elections, or countless other things directly immediately affecting their lives, that’s not the case. It’s more that humans A) are bad at caring about the future and B) don’t trust scientists for any number of reasons they wouldn’t trust any other human meaning C) the only way to change this is to convince them, not lecture them, just like any other group that wants power, because no group is intrinsically special regarding human communication.

I made fun of the 'America First' campaign slogan and referred to it as 'America Only'.

Then you can quickly use this idea on people who put themselves in front of others. And the reality is it's not about being first, rather it's only about them, not what comes after them.

"Especially in light of some of the burgeoning anti-Asian sentiment, for instance from Helen Andrews and some others."

Huh? I had to look up Helen Andrews. From Wikipedia: "She wrote that wokeness is fundamentally female, as it prioritizes 'empathy over rationality, safety over risk, cohesion over competition.'"

(And coincidentally you have "Rice Theory: Why Eastern Cultures Are More Cooperative" on the front page and I can see how in her mind there is a line between "wokeness" and "cooperative".)

I considered writing an app you would take on a car ride that would record accelerometer readings indicative of a pothole. Geotag the reading and push is anonymously to a server.

Enough events should show clusters where potholes likely exist. You would think cities would love that kind of data.

This may sound a little cynical but cities often don't like having an inventory of infrastructure problems because it creates an obligation to address it or pay for tire/rim damage if there was prior written notice of a problem. I saw this happen with sidewalk condition data as another example.

Awesome. Eagerly awaiting Line Rider.

Feels like building proteins, or some kind of RNA/DNA molecules.

Love these deep dives—perfect HN fodder. Add to that articles like this also on the front page today: "Algorithmically Finding the Longest Line of Sight on Earth," "Tesselation Kit"…

HN, keep being HN! We love you.

A hobbyist analog computer I will open-source.

I have been through a number of iterations of adders, integrators… It's starting to coalesce now into a finished PCB. (Iterating is slow though at the PCB stage since we're round-tripping via Asian PCB fabs.)

As often happens, I want to learn about something (analog computing in this case) and I find that a deep dive where a kit comes out at the end is an enjoyable way to explore (I also get more experience with KiCad and, for this project, SMT).

The seed of this were a few articles on building a "lunar lander" circuit in early '70's electronic hobbyist magazines I found online. Pre-home-computer, how does one create a lunar landing simulation? Why with op-amps and panel meters of course.

And so that is where I began. But I'm way past that now though by making instead a general purpose analog computer.