This is the sort of article that makes me imagine a dialogue between a senior software engineer and a newb developer that goes something like this:
Newb: Hey man, I think for this project I'll write my own SQL datastore from scratch. I've looked at a bunch of them and my project, which is basically an inventory management system, is such a special snowflake that it needs its own datastore.
Senior: That would be insane. Never do that. Use what's already out there, and is tried and tested. In fact, just use postgres and make it work.
Newb: Aw, ok. I was so much more excited about writing a new SQL datastore than I was about the actual project it's for, but sure, I'll just use postgres. starts to walk away...
Senior: Hold up a sec before you go, I want to run something by you. Because our discipline, which is basically a team of people who are hired to build things on a schedule, is such a special snowflake, I've invented this totally new way of thinking about work, and of organizing a team and leading it, and there's a bunch of new terminology and I have some cool diagrams... I'm lobbying that we all switch to this at the end of the month.
You just might not have experienced decent leadership.
Servant leadership doesn't mean you do what your reports want. It means you enable your reports to make good decisions, instead of deciding for them. It doesn't mean you don't teach, or you don't share experiences.
Let me quote from the original: "The best test, and difficult to administer, is: Do those served grow as persons? Do they, while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become servants?“
Do you think the senior can answer "yes" to this if they just acquiesce to everything?
I did an MBA, and have built and led software dev teams for decades. Just to establish my bona fides, because the "known art" of building cohesive teams and what actually works for software teams is definitely two different things.
Actually, having talked to friends in other creative industries, I don't think anyone gets this right for creative processes. And I think TFA gets it completely right when it talks about estimation as the root of the problem.
We know there is no method of correctly estimating software development timescales before the development begins. This is also true of other creative processes, but usually they have the ability to ship a half-complete product. Think of writers meeting a deadline with something they know isn't "right" but doesn't actually burn the reader's eyeballs out of their skull. Or graphic artists who have to send something off that they know isn't great, etc.
Software actually is unique in this respect, because it doesn't work if it's not complete. There are bugs that need to be fixed, features that actually need to be complete, etc. While a graphic artist will usually get a couple of requests for changes, there are usually contractual limits around this. No such luck in software (imagine saying to your customer "you can report two bugs or incomplete features for free, then we start charging you again").
So the basic problem (as TFA says) is that estimates are never accurate, and yet businesses need accurate estimates to make decisions. A good software team leader/project manager/CTO/IT Director/Tech Wiz bridges this gap and manages both sides so that the business can function.
To do that requires empathic understanding of the needs of both sides.
Authoritarian leadership, either from development refusing to heed deadlines, or management insisting on them, will (as TFA says) break the business. Servant leadership allows both sides to make the necessary concessions to keep the business afloat.
Awesome that someone has written this up so well :)
> Software actually is unique in this respect, because it doesn't work if it's not complete.
This is a point that really ought to be more broadly recognized.
It's a pervasive issue throughout software development, and while the situation is improving I'm not convinced that's about any kind of improved design. It mostly seems to be a function of delivery mechanisms which can circumvent the problem - internet delivery of patches, automatic updating, and remote hosting of apps have all lowered the bar on "good enough to ship". The most obvious example is almost certainly video game development: planning and labor conditions haven't substantially improved, but the prevalence death-march development has been made much better by the ability to gracefully patch games after release.
"You can't ship a partial product" isn't universally true, of course, but building projects which can be shipped while incomplete requires planning for that option from the beginning, and has real tradeoffs. In general, software planning seems to either ignore this issue entirely and go vastly over schedule, or propose some agile/lean/extreme 'iterative' process without paying any attention to the requirements and costs of that approach.
Imagine telling a construction firm that you want a two-story 'minimum viable building' that you can work in while they add the remaining stories if things run over schedule. If they didn't refuse outright, they'd charge you double and design the entire process around that condition.
Actually, that metaphor seems like a pretty useful one. Both fields involve developing something which can't be delivered at intermediate stages, where iterative never-broken development is slower and more difficult, and where both unforseen (e.g. unmarked water main) and unforseeable (e.g. storm damage) problems can arise throughout development. And, consequently, both have a well-earned reputation for late, overbudget deliveries.
To be fair, we can all totally ship incomplete and buggy software to good effect. Imagine a shipping system where users have to submit orders and then manually update the address zip code--sure it is buggy but the end user still gets value.
This is true, but it doesn't mean software can be delivered at any point in the development process.
Something like a novel is (hopefully) shipment-ready at most points from the first draft on. A full rewrite might happen at some point, but much of the development process happens after the first draft and can be interrupted with minimal cleanup. If you've only copy-edited half of chapter one, you can still finalize those changes and ship without trouble. And, you're unlikely to get 95% of the way through writing and discover an issue in Chapter 10 that invalidates chapters 2-6. (This does happen, especially with mystery novels, but it's not the standards outcome. It's much more likely to just hit a problem that makes you want to rewrite, rather than actually breaking the piece.)
A lot of software has a high percentage of work happen ahead of the MVP, and even if progress past the MVP is done while maintaining a working state, the individual tasks don't tend to be interrupt-able. If that shipping system is instructed to handle bulk-loading of 50,000 orders, fixing the manual zip code issue is probably still an all-or-nothing task. And, of course, there's a high chance of invalidating past work. If a contract comes in that requires multi-user ownership of orders, that might break invariants across the entire database while still looking to the buyer like "just adding another user to my order".
Pretty much any field has some minimum unit of work to move between acceptable states. You might print a novel mid-editing, but not while a sentence is half reworked. You can launch a new car model with fewer units finished than you'd like, but not (easily) with contracts for dealers that will be unfulfilled, and certainly not if you find a problem with the airbags.
Software development frequently gets planned like creative or social work which generally has small minimum increments and few catastrophic surprises, but ends up playing out more like construction or physical manufacturing where unexpected failures are likely and shippable states are noticeably far apart. Hence death marches, outright broken releases, and a lot of the other issues the field is infamous for.
I can't think of another discipline like software engineering. Most other disciplines where you build things you reach a point where you deliver the product and then you're done with it, there might be some maintenance but the period of major changes is done.
In software you might have a building full of engineers working on the same product for years after it was initially delivered, adding major features, making deep changes. The level of continuos delivery doesn't exist in other fields.
Sure it does. It exists in construction. You build a building to spec, and then that building is constantly outfitted for new tenants, remodeled, and renovated for decades if not centuries.
Yeah, but the original teams that designed or built the building are long gone, and in many cases the tenant/remodel work can happen without any of the original blueprints. Buildings are meant to be modified, and this is why we have building codes, subfloors, ceiling tiles, etc. In commercial software, the startup hurdle is so great, that it usually means only a team that is contiguous with the original construction team can economically extend the original in a meaningful way.
Open source requires a different way of thinking about it; not all software can be open source. Not all buildings can be raised like a barn. In fact there is very little in the construction or civil engineering world that matches what happens in open source software.
This analogy is one of my personal favorites for software development. The machine that is going to be running the software could be considered our building. The hardware of the machine is designed to exacting specifications by people that typically hold university engineering degrees and is much more reliable than software typically is, it has to be or nobody would use it. Failure of the building is catastrophic to the tenants.
A process could maybe be considered a room within that building and adding functionality to that process is akin to adding furniture to a room, or I guess, doing a buildout for a tenant. You add specific furnishings to help you accomplish specific tasks within that room.
This analogy breaks down pretty quickly, but think about the room here. I can now explain to a non-technical person that this software (a single process in this case) is like a broom closet that we've shoved full of old furniture for the last 5 years. Prior engineers have stacked tables to the ceiling, filing cabinets have locks without keys. We don't even know what's in the back of the closet at this point, and getting a peak at what's in the back will require unpacking everything at the front.
On the other hand you could have a different room. It has doors for egress and ingress. It has glass walls so we can see what's happening at all times. We carefully arrange the furnishings for efficiency, and can swap out old furniture for new in a matter of moments. We regularly clean the room, removing unused/aging equipment etc... When people enter that room to work (end users) the workflow is effortless and intuitive.
So as a software developer/engineer or whatever you call yourself, we're more like the contractors that buildout interiors for specific use cases. We equip the rooms for doing specific jobs. You give us the building or even just one room and we'll make it useful.
To a newb just using Postgres should be new and exciting. It's such a rich database I am still learning, even after years using it.
Maybe that was just a bad example. But I don't know, even just using old HTML and CSS to set the page is always interesting to me, because there are always problems to overcome. How do we make everything fit on the page without it being cluttered? How do we let the user do this thing that they want while also not interfering with this other thing that they say they want?
After many years, I like to use old, established pieces, but fitting the pieces together is what I find interesting.
At the same time, when I was first starting out, there was a greater urge to roll my own. I remember rolling my own diff program, in PHP. It was worse at diffing than figuring out how to safely pass the inputs into the shell, and just using good old diff, but it made me happy and it was a useful mental exercise. Newbs need to stretch their wings and see how far they can fly. Their flight is probably much worse than just hopping on the ol' jet. It's a hard problem.
A little bit beside your point but I like your example and agree with it.
In the example the Senior IS the Newb at whatever team/managerial issue is part of their new frontier. Unless they have experience to run those ideas by they don't have anyone to point them to "postgres".
I'm not sure the applying the ideas in the article requires Servant Leaders™ to explain to the people they're leading what Servant Leading™ is. I read it more as, if you're in a leadership position, here are some ideas which might make you more effective.
In my personal experience, Dry-rb is the "bargaining" stage of grief over the current state of Ruby and Rails. When you finally reach "acceptance," you move on to another stack entirely.
My experience is that people who come to feel about Rails the way he describes in the intro (I went through this exact progression, myself) end up moving on to another stack entirely, typically either Elixir or JS.
My personal shift has been to JS, because you do can everything from front-end to AWS to postgres (via plv8) with it -- it covers the whole stack. And with the advent of ES6, it's just not that bad as a language. It's not great, but it's not the misery it once was, either.
As the author says, Rails is great for starting out. It's great for starting projects, and it's great for starting as a web developer. But I know first-hand the pain of growing and scaling a monolithic Rails app that he speaks of, and for projects that I start from scratch I no longer use it.
I'm only testing Lambda functions with it, and not really testing APIG + Lambda integrations or anything fancier.
I prep the local db, mock a Lambda event, write the mocked event to a JSON file, then use command line options to run the event against AWS SAM local, then get the response and compare it to the expected response.
I totally buy it that there is no such thing as an "unidentifiable alloy." I also buy it that journalists, not being materials scientists or indeed scientists of any sort, do not know the difference between an "alloy" and "a hunk of some hard material," so at some point they wrote down "alloy" because the word sounds exotic, like something you'd find at Area 51.
This happens in the press /all the time/. Journos get specific terms of art wrong, and nitpickers nitpick and clarify. I know this because I made a career of such nitpicking and clarifying once.
My point here is that nothing put forward in this article means that there's not a building in Vegas with some kinds of materials that have strange properties and we don't know where they're from or who made them or how. It just means that said materials are not properly "alloys" and the journos got that word wrong, as journos often do when they're way outside their area of expertise.
> a building in Vegas with some kinds of materials that have strange properties and we don't know where they're from or who made them or how
A lot stranger things have been found hidden in Vegas buildings than alien artifacts. Just a few weeks ago it started raining cheerleader uniforms in downtown Las Vegas because a demolition crew pulling down a hotel hit a sealed-off room filled with thousands of them.
It makes me wonder what it will look like when they tear down the building storing old Star Trek: The Experience junk. The UFO conspiracy theorists are going to have a great time with those photo.
You know, I saw something like this in Boston just yesterday. They are tearing down a condemned parking garage near my office; I saw a room they had started demolishing that was packed chock-full with what looks like winter clothes. Like, they had been stuffed in it as insulation or something. Some had fallen out onto the rubble below. Very strange.
Yes, agreed. I hate to say it, but this is a crap article. The point of the original NYT article was that they had something they could not identify, not that there was some new form of matter. All this consists of is a journalist (and hopefully editor) using the wrong phraseology and SA jumping on it like an eager five-year-old on the mechnical fire engine at WalMart.
SA used to have a series, I think it was called something like the "Citizen Scientist" or maybe the "Amateur Scientist". This article is a new type of journalism I've noticed taking off in the last decade or two that I'll call the "Asshole Scientist". It consists of self-righteous and assine authors taking pot-shots (some warranted, some not) at whatever cultural item is in the current zeitgeist.
It's great for gathering clicks. Nothing like a bunch of folks sitting in their living room with a smug smile on their face, scrolling through a short journalistic snack-food, feeling like they're in with the cool kids. But it doesn't do much in the way of showing people how to have reasonable public conversations. Or even how to read charitably.
Note that I'm not upset with the content of the article, just the tone. A bit of tweaking and it'd be fine. But that would defeat the purpose. This kind of article is all about tone.
What is the distinction between "material that you can't identify" and a "whole new type of matter?"
Unless something is interfering with the efforts to identify a given substance, there aren't a whole lot of options left besides it being something "new" (which is to say hitherto unknown).
It's as if somebody had been quoted saying "The UFO appeared to be surrounded by some type of brightly glowing plasma" and Scientific American were to go get the opinions of plasma physicists about whether or not this was possible with plasma.
What the material scientists are saying is that there are techniques which would allow them to identify any physical material given that our understanding of the way that they universe works is approximately correct. If a material was discovered that was unidentifiable the government would not be putting it in a warehouse, anywhere, it would be in a massive secret lab. All the people who SA interviewed would have been co-opted into joining said lab. Undergraduate education in Physics and Chemistry in the US would be grinding to a halt, NIST grants and DARPA grants would be zero for any other topic, publication and patent rates would be falling precipitously.
Why? Because such a find would be "all bets are off" everything would be up for grabs, not only would every scientist be scrambling to be involved - all the others would be encased in dark depression knowing that what they were up to was essentially worthless.
There would be questions in the UN, threats of violence against the US, allies would be sending worried missions and publicly begging for inclusion (unless they were included in which case they would be mouth shut deferential and smug in company..)
The Bomb was a game changer, everyone working on the Manhattan Project knew it, and they _still_ had spies successfully infiltrating the project and exfiltrating above-top-secret data. Some supposedly alien material wouldn't change human nature. Something that big would leak.
It did leak. Everybody "knows" the government has been experimenting on Aliens and alien technology since at least Roswell. There are even articles in the New York Times about warehouses storing alien artifacts!
That is a good point. If you were in possession of world-changing, society-breaking, panic-inducing information, how else would you prepare society for eventually hearing the full truth?
You would do it as a laughable joke over a long period of time.
That is why they stopped trying to outright hide projects like that, and instead mix the truth in tsunami of disinformation, sensationalize, crack pot theories, conspiracy, and the like so even if legitimate "Top Secret" info was leaked it could be safely dismissed as conspiracy, lies, or the newest term "fake news"
Obviously the narrative you put down makes no sense whatsoever, game theoretic and otherwise. For a better, much more realistic understanding of how intelligence agencies may react to something like this, I suggest you read Richard Heuer's psychology of intelligence analysis [1].
It's even stupider than that. The original quote was "alloys and other materials", but all the "rebuttals" are strictly about alloys in particular. They just ignored half the sentence they were nitpicking and declared the whole thing rebutted.
Yeah, if you are willing to buy that they have something stored they can't identify, this is the most logical explanation.
That said, I would still buy that there are probably almost no materials that we couldn't at least get a handle on. If they were truly incomprehensible it would likely be because they were the result of manipulating properties that we don't even know exist yet (higher dimensionality, etc, whatever other sci-fi shit), and I feel like something that sensational and world changing would be incredibly hard to cover up.
A Pentium chip would probably seem like an incomprehensible material to Alan Turing (and not just because of the awful instruction set), because even though all the materials were known at the time, the design and fabrication techniques and mind-bogglingly fine granularity and complexity of how they are combined hadn't been conceived of yet.
I agree the reporters probably flubbed the word "alloy" for lack of a better understanding of science or a better term to describe it.
An integrated circuit is a fine grained combination of several different kinds of metal and other materials, but they're meticulously arranged and sandwiched together, not just melted together into an alloy.
At what point do you draw the line between nanotechnology and alloy, when you have the technology to 3d-print each and every atom?
>I agree the reporters probably flubbed the word "alloy" for lack of a better understanding of science or a better term to describe it.
There's no mention of what properties these materials are supposed to have, much less that the materials seem so exotic as to be beyond comprehension or a more accurate description. The original New York Times article merely mentions the "storage of metal alloys and other materials..."
Turing could see the recognizable structure and after probing it a while would quickly work out its function. He would understand all the bits and pieces and almost instantly speculate on how it was manufactured. Something alien would be more akin to showing Plato a laser pointer. Plato could spend a lifetime poking at it without learning much of anything. That's the sort of material they would need to lock up.
It depends on what how old Turing was... if it's 20 year old Turing -- an electron microscope wasn't invented yet... so no, he couldn't use one to see all of the structures of a CPU.. just the larger structures visible with an optical microscope (limited to ~200nm (Rayleigh criteron) but I dont know if they had the lens manufacturing good enough back then to reach that limit)... which may not be enough for him to figure it out.
Edit: And even when he died in the 1954, electron microscopes werent that advanced... we still needed to invent new techniques, improve our lens manufacturing, etc. There were a lot of shortcomings with it back then that limited its usage. So even in his later years, I wonder how much detail he could actually see on a modern CPU.
Of course he could, but unless you told him you were a time traveler from the future, or the Germans had vastly superior secret technology they hadn't deployed yet, it would be so unlike the computers of his time that it probably wouldn't seem plausible that it was what he knew of as a computer.
Alloys, composites, raw materials, you can identify them. If they have atoms you can identify what is in them. Now there could be weird materials that are hard to more difficult to identify. But you need a more compelling argument.
While I agree that journalists are often wrong (sometimes intentionally and sensationally so), it's 100% fair to say that the top metallurgists among us almost certainly cannot identify every extant pure metal and alloy in the entire universe.
There are other thermal, gravitational, and energetic environments in the universe that we probably haven't even begun to understand.
We are still learning how the universe appears to work.
What kind of scientist can draw a conclusion without having conducted any sort of observation? That kind of closed-mindedness is totally damning to human understanding.
The nice thing about atomic theory is that it doesn't really have that kind of hole in it. If you find, say, a sample of an island-of-stability metal you've never seen before and didn't even think was all that likely to be able to exist, you can still study and characterize it in terms of those materials we are more familiar with. You're right that we don't understand everything about the universe. But what we do understand generalizes well enough to cover the "alien alloys" case.
The alternative possibility is that there are places in the universe where fundamental physics works totally differently from here, yet materials formed there can exist here in an apparently stable state - an entire second physical system, never so much as hinted at in any of our own investigations. That would be considerably more surprising than a reporter through ignorance and haste having mischaracterized the content of a story! Reporters do that all the time.
Don't forget that Larry dated Marissa for a long time, and she was his subordinate. And then there's Eric, who was notorious...
Anyway, my understanding was that it has historically been OK at Google to date subordinates, so I'm waiting for more to come out because I can't imagine that "he had a consensual relationship with a subordinate" is all that's going on here.
But maybe someone who has worked there for a long time can correct me?
Full disclosure: used to work for Alphabet, and while I seem to recall the sexual harassment training on this pretty well, take my word with a huge grain of salt.
Google has a pretty open-minded approach about relationships: you won't get fired for starting a relationship with a report/manager, but you are required to disclose it to management and take the appropriate steps to fix the power imbalance. Moving the parties to two different teams is one of the suggested solutions. I could see that being hard to achieve if you are in the board of directors, but it should work for the vast majority of employees.
So my guess about this "inappropriate relationship" was that it wasn't reported and the proper actions weren't taken. I hope for everyone involved it was consensual and just an indiscretion, rather than something more perverse being at play.
no one gives promotions at Google. They go to a review committee who decides if the person is performing above their current level. It is possible he wrote for her promo committee packet, but managers are generally not as important as peers in the promo process.
One interesting aspect people are missing in this thread is that the power dynamic goes both ways: a manager could coerce a report into a relationship or a report gets unfair advantage over their peers by exerting influence on their manager. Or both. Not only that, it opens the door to blackmailing.
That's why the dynamic is bad and people trying to make a defense of it (I've seen co are misguided or haven't considered all the factors. There's a reason why there's a legal-approved training on this.
It's not clear from the article, but it might be that someone other than the subordinate complained. Perhaps he had given this subordinate preferential treatment. That would be grounds for pushing him out.
Was this the same as Bill and Melinda? But isn't Andy Rubin married?
There's two couples who are married (with children) at work and I think they met at work too. It's a nice dynamic... but only because it worked out :).
No I didn't miss it. That's what I'm saying -- there has to be something beyond "consensual relationship with subordinate" going on here. The fact that someone complained to HR supports that hypothesis.
My point was that sleeping with subordinates is not historically the kind of thing that gets people fired at Google. I make no claim about whether that's good or bad (whether or not that should ever be ok is a different discussion), just an observation that that's the way it has been, which (along with the HR complaint) indicates to me that this wasn't a simple case of Rubin sleeping with a subordinate.
Please don't get your history from The Oatmeal. If you want to read a real account of what Edison actually did, the opening chapters of this classic are great:
Why was the title edited on this? There is nothing wrong with the title assigned by ProPublica, and in fact it's far better than the one above. Submitters, please stop doing this.
Yeah it was slashdot that sent me to the embryonic Ars to find out all about Pentium2 (or was it 3?) architectures, BeOS, and this new-fangled unstable unixy MacOS in beta etc.
Sadly these "deep dives" feels more and more shallow these days. More and more they are about "look and feel" or pixel counting rather than the meat and potatoes.
Frankly these days Ars Technica could just as well be relabeled Apple Technica. The site scuttled their coverage of FOSS and similar under prominent sections, while the Apple stuff keep leaking out from their "infinite loop" section.
These days if it is not Apple related, it gets binned under their generic "gadgets" section.
And this from the site that got me interested in Linux in the first place back when it was black and orange, and housed a multipage introduction to Linux internals.
You seem to write almost exclusively CPU and tech articles. Good for you. I wish your co-workers would stick to technology and lay off pushing politics.
[edit] Wow, the moderators couldn't even tell I was complimenting the guy.
I know right? I don't feel like my opinion was really that controversial.
Ars Technica has been a bittersweet story for years in all of the communities / circles that I hang out at. Some of their articles are great journalism. Others make you pine for "the good old days".
I wish they'd bring back Computer Gaming World. That was the gold standard of computer journalism. You can actually find PDF's of every issue ever released online and if you compare them to today, they used to be so methodical and objective. They didn't read like advertisements and there was no forced-in message about the political climate. You didn't read about Battle Chess and get shamed for liking that the Queen looked pretty.
Newb: Hey man, I think for this project I'll write my own SQL datastore from scratch. I've looked at a bunch of them and my project, which is basically an inventory management system, is such a special snowflake that it needs its own datastore.
Senior: That would be insane. Never do that. Use what's already out there, and is tried and tested. In fact, just use postgres and make it work.
Newb: Aw, ok. I was so much more excited about writing a new SQL datastore than I was about the actual project it's for, but sure, I'll just use postgres. starts to walk away...
Senior: Hold up a sec before you go, I want to run something by you. Because our discipline, which is basically a team of people who are hired to build things on a schedule, is such a special snowflake, I've invented this totally new way of thinking about work, and of organizing a team and leading it, and there's a bunch of new terminology and I have some cool diagrams... I'm lobbying that we all switch to this at the end of the month.