4 ms·
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
by JKCalhoun 9mo ago
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!
- hippo22 9mo agoI don’t have anything to add other than to say this was beautifully written.
- dzonga 9mo agoyou 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.
- kamaal 9mo agoIts 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
- bestthrowaway 9mo agoI 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.
- abustamam 9mo agoHonest 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.
- MathMonkeyMan 9mo agoIt 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.
- senfiaj 9mo agoI'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.
- konart 9mo agoModern programming careers _are_ factory jobs. Until you have some sort of senior+ position you are literally just standing in front of a conveyor line.
- wsc981 9mo agoAt 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!
- bitwize 9mo ago> 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.
- port11 9mo agoI’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.)
- JKCalhoun 9mo agoI 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).
- port11 9mo agoI 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.
- tom_m 9mo agoThanks 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.
- chasd00 9mo agopeople 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.