davidrupp

Perhaps followed by progressively higher tax rates on subsequent books and apples?

Why do you not think there’s any acceptable reason for owning several homes?

Full title: "Respecting What Came Before, Premature Optimization, the Pitfalls of Sensationalism and Technology Enthusiasm"

I smiled. And I assumed it was tongue-in-cheek.

(Some of) Werner's advice in his own words (from the linked article):

* "I always urge builders to consider the evolution of their systems over time and make sure the foundation is such that you can change and expand them with the minimum number of dependencies."

* "There are few one-way doors. Evaluating your systems regularly is as important, if not more so, than building them in the first place."

Bookmarked; thanks for that link. Bonus points for sentiment analysis.

Not sure how this translates to "rules" in a cellular automaton, but: https://en.wikipedia.org/wiki/One-instruction_set_computer

I like both Hooktheory and iReal Pro [1] for hearing what chord progressions sound like in practice.

[1] https://www.irealpro.com/

Friendly vocabulary note: I think what you mean by "pneumonics" is https://en.wiktionary.org/wiki/mnemonics .

I was just discussing something like this with my team <usual-disclaimers/>, and dropped the obligatory Knuth quote:

“The best programs are written so that computing machines can perform them quickly and so that human beings can understand them clearly. A programmer is ideally an essayist who works with traditional aesthetic and literary forms as well as mathematical concepts, to communicate the way that an algorithm works and to convince a reader that the results will be correct.” ― Donald E. Knuth, Selected Papers on Computer Science

Notice "human beings", plural; so not just the person who's writing the code.

I've asked my team at Amazon [usual disclaimers] to read this, and highlighted my favorite takeaways: "Well-timed sleep was probably the most important thing I did", and "Using sleep to do the heavy lifting on algorithm design". I love this concept, and need to incorporate more of it myself.

Ideally: Travel point-to-point, rather than constrained by roads, turns, intersections, all competing with similarly-constrained traffic. Congestion en route would largely go away (although we would probably adopt "lanes" of travel analogous to what the airlines use) and would be replaced by congestion at popular destinations (again, much like the busiest hub airports).

I think a more feasible variant of this is a small platform on which the pilot would stand or sit, or from which s/he would hang, lifted and driven by the equivalent of multiple battery-powered drones.

I had just switched from IBM 370 mainframe assembler to Java in mid-2000, worked for several months at iXL, a then-typical consulting company with high margins and correspondingly high "bling" -- elaborate office furnishings, massive plasma TVs in the conference rooms, massages, beer cart Fridays, et cetera. That got crushed in the dot-bomb, followed soon after by 9/11. I managed not to have to return to my former vertical (airline reservations), but I definitely had to scramble to stay relevant. I work at Amazon now (usual disclaimer; opinions my own, etc.).

Bummed that I can upvote this only once. Excellent work.

I haven't yet, beyond some quick comments I've posted on other HN threads. I may capture it in long form after I've retired. My career has taken a meandering path, and there have been aspects of it that I think might be entertaining to the right audience. If there's something specific you're curious about, I'd be happy to try to address that.

This was the model when I joined Eastern Airlines' reservation system (aka, System One) out of college, although the training was entirely in-house; IBM was not directly involved, that I could tell. I enjoyed spending the first few months of my career getting paid to sit in a classroom and learn this stuff.

I made the switch from IBM/370 assembly to Java around this time. It was a good six months or so, with Beer Cart Friday, weekly free massages, and massive plasma TVs in the conference rooms (at iXL in Denver). It was a rough few years after that.

$50/hr, good heavens. My salary for my first professional job out of university was disappointing even for the time; it wouldn't qualify as minimum wage these days, some places (U.S.). But I worked with great people on interesting problems (airline reservations in IBM/370 mainframe assembly language). And I had flight benefits, which I made good use of.

My go-to was Softpro Books in Denver. I would scan the shelves at B&N and Borders too, just in case, but Softpro had a much better selection.

The part that specifies "which transitions are possible and which are not" (more precisely: which state results from a given state and input) -- known as the state-transition function [1] -- is a necessary component of the state machine definition. If you don't have that, you don't have a state machine in code; you just have a bunch of functions.

[1] https://en.wikipedia.org/wiki/Finite-state_machine#Mathemati...

My first job after completing mine gave me ~25% pay increase, and it's gone only up since. I don't claim this is causal, but I'm not displeased with the correlation. Personally, I found I enjoyed the coursework more than I had during undergrad, and I challenged myself to strive for actual mastery of the material, rather than just doing the minimum to get the credential.

https://www.youtube.com/watch?v=DmbGs290qeM -- Dr. Knuth sets the record straight at a talk being given by Randall Munroe (of xkcd fame). Spoiler alert: "I only met him a couple of times [...] and in each case I was impressed by him probably more than he was impressed by me."

Because people are more than just the skills they have that happen to apply to their current job function. And because management requires a skill set that -- like many others -- can be attained by someone who is willing to work to attain it.

I think of it in terms of leverage. If I knew for sure that my becoming a manager would let me be a force multiplier for my team, that they would all be enough better to more than compensate for losing me as an individual contributor, I would consider making the switch. Having been a developer myself, I would have insight into what gets in their way, and I could use my managerial powers For Good™ to get those things out of their way. At least that would be my intent. I've had excellent managers who had been good developers who chose this path.

Having said all that, one of my first managers early in my career was a high-functioning developer who was moved to a leadership role because that was the default expectation. He was a terrible manager; he played favorites and treated his responsibility as authority to be wielded against those he didn't like. I was fortunate that he liked me, but he stifled the early careers of some of my friends who were at least as good at the job as I was. So there is something to be said for not having developer-to-manager as a default expectation.

I don't speak for my company, but in my opinion they still get more value from me, net, as a non-manager than they would as a manager. I also think some of the most valuable work I do is not in the code I write or the systems I build myself, but rather in the guidance I can give junior developers on the things they build, and the way they approach their careers. If I get can someone in her 20's or 30's to adopt a useful technique or perspective it took me much longer to acquire, everyone wins. As Andy Jassy says, "there is no compression algorithm for experience". But there is opportunity to learn from someone else's uncompressed experience so that yours going forward is that much better.

[Everything that follows is my personal opinion. I do not speak for my company.]

Seven years and counting for me, and likewise proud. I have found it a good experience, on balance. I have witnessed -- and been subjected to -- behavior by individuals that people would reasonably consider "toxic", and I've been fortunate to have avoided long-term impact. I do what I can to fight it where I find it.

To the point of remote work, I've been primarily remote the whole time, and it's worked out well. If enforced RTO ever does happen (I don't expect it to), I'll have a decision to make, is all.

If I want information on medically related things, Wikipedia is my go-to. I skip Google (actually, DuckDuckGo) altogether and just start my search on the Wikipedia home page.

Sr. SDE (L6) @ Amazon; everything expressed here is my personal opinion; I do not speak for my company.

On the whole, I think the article is good. I would rather they quantified the bit about "most Amazonians seem to get satisfaction from making a behavioral round intense". The interviews I conduct are not about my satisfaction at all; they're about gathering the data I need to make an inclined / not-inclined decision.

Data and impact / Talk about "I", not "we" / Be as technical as possible -- I ask candidates up front to emphasize these things, and I remind them as necessary throughout the interview if it seems like they're wandering. "I" not "we" is particularly hard for some people, because they reasonably want to come across as a team player.

Name-checking leadership principles -- I don't mind this in and of itself; it can be helpful to have a common framework to discuss the relevant concepts. But candidates should not just use them as a shibboleth; they need to demonstrate that they understand what a given LP actually means in practice, and provide data about how they've applied it to their past work. Casually working in the phrase "customer obsession" three times is not going to make Andy Jassy appear in a puff of smoke and offer you the job on the spot.

More info at https://en.wiktionary.org/wiki/spiel . Pronounced as you (gp) spelled it phonetically because it's borrowed from German.

> It's on github

... at https://github.com/kanaka/mal

Fun fact: I got to work with Joel at a Clojure-based startup, LonoCloud (since acquired by ViaSat). Super sharp dude, and very helpful about MAL. Definitely recommend.

They also evolved from the original Airline Control Program (ACP), which was written in the 1960's, at which point assembly was pretty much the only way to get the level of performance required. I think there was some incidental "vendor lock-in", given that IBM was so dominant in the mainframe space for so long, but I think the more relevant principle is "conceptual lock-in", kind of like why banks still rely on COBOL. There was such a large investment in assembly that rewrites into higher level languages -- and we did consider them -- were prohibitively expensive.