Chrome was delivered without any sprints at all (2021)
twitter.com
twitter.com
> I’m in the relatively rare position of having worked on both Chrome and IE3. To add all the truth @aboodman wrote, both teams were amongst the best I’ve worked with, but Chrome was much healthier, happier and more supportive. Senior industry folks helped.
I find this kind of funny, because this is what happens right? I was under the assumption that architects typically design the building plans and do all the engineering, and a construction crew (which can consist of people mainly in their 20s) will build those plans under the supervision of the lead engineers/architects.
So, in the same way that many senior software engineers don't write much code, don't architects/civil engineers typically refrain from using power tools to build the actual building? If this is the case, then software engineering is very akin to other engineering disciplines in this regard.
I feel like the author of this tweet is conflating craftsmen with senior leads. A craftsmen is somebody I would expect to have been working with the medium for 10+ years, and continues honing their craft throughout the years. Whereas engineers and architects are typically more concerned with the abstract ideas and overall outcome. An engineer/architect can be a craftsman, but I don't believe they need to be synonymous.
"But we have to have websockets, it's in the presentation!"
I'm still confused that this number is so high.
Draftsmen can also draw up the plans rather than an architect. There are different educational requirements as well as trade requirements before each can begin practicing said trade. (You can't just call yourself an architect just because your last employer gave you that title! both require professional licenses too.)
Plans are approved by a city official and permits are given. A contractor is hired to build based on the plans, and they hire subcontractors. The result often has to change due to unforeseen circumstances, and usually those changes don't result in a redesign. If the contractor sucks balls, the result will be a tire fire unfit for disaster relief housing. If the contractor is good, nearly everything will go as expected, it will be delivered on time and on budget. In between those, a lot of shit gets swept under the rug.
does it happen that the #1 thing is blocked by some dependency? (do you simply move to #2?)
how do you manage a team? (do they work on your list or they have theirs?)
Yes if #1 is blocked then I work on #2 until #1 is unblocked. And if #2 is blocked then I work on #3 etc.
I use a single prioritised list to manage teams. The list is public to the team and I rearrange it as needed when new discoveries/obstacles warrant it. I also let team member choose which tasks they want to work on. As long as it is one of the high priority tasks. I don’t know if individual team members have their own list. I don’t care how they do their work as long as it gets done at high quality.
I also publicly list tasks completed and the people who completed them. It makes it very obvious to everybody who the most productive people are. It’s a great motivator for the team because everybody wants to be #1.
I think V8 was not actually that complicated - a lot of the "deep" computer science they originally wrote and talked about in marketing material was from the 80s, and things like the hidden classes were picked up almost immediately by JSC at least (as in just a few weeks of non-crunch time). The original JITs for V8 and subsequently JSC were essentially template JITs, i.e not particularly complicated (for JSC the big issue was having to support x86, x86_64, and Thumb2, and managing the security implications on iOS). Even the GC imo wasn't super impressive.
The primary reason that Spidermonkey and JSC didn't have the JIT or hidden shape concepts wasn't engineering complexity, but simply that at the time the apparently important perf problems were with other parts of JS and the DOM - so huge numbers of objects (the argument for generational GC), and non-dom property access (which recall was not optimized in V8 at the time) were just not considered that important compared to other parts of JS and the browser.
But when you get to WebCore and the browser the Chrome folk did a lot of very hard work, the process separation was also conceptually simple, but practically a huge amount of very complex work. You can contrast the difference in time it took to get JS engines performance up to the same order as V8 vs the time it took any degree of process separation in WebKit and Gecko. The first multiprocess Safari was just two processes, the app, and the render process - just getting WebKit going with a single separate render process was a lot of work, it was at least two full releases before true multiprocess was a thing in WebKit (WebKit's multiprocess model makes the process separation part of the engine, vs. the blink model of having the app be responsible).
Then for sandboxing, WebKit obviously got to leverage the Mac+iOS sandboxing that was built into the system. The chrome folk had to build an entire sandboxing system for windows, without kernel support, or in fact any support. Which was another gigantic amount of work.
So kudos to the chrome team, they did a lot of work, and a lot of it was very hard, and shouldn't be reduced or dismissed.
"Management made the decision to transition our business completely and pursue the market for web browsers. Tim Krauskopf, the founder and head of development, asked me to write a web browser. I started work on Spyglass Mosaic on April 5th, 1994. The demo for our first prospective customer was already on the calendar in May.
I ended up as the Project Lead for the browser team. Yes, we licensed the technology and trademarks from NCSA (at the University of Illinois), but we never used any of the code. We wrote our browser implementations completely from scratch, on Windows, MacOS, and Unix.
We were not the first Mosaic licensee, but we were the last. Prior to us, a company called Spry took the Mosaic code and tried to sell "Internet in a Box". People still seem to get Spry and Spyglass confused because of the similar names."
"Internet Explorer 2.0 was basically Spyglass Mosaic with not too many changes. IE 3.0 was a major upgrade, but still largely based on our code. IE 4.0 was closer to a rewrite, but our code was still lingering around -- we could tell by the presence of certain esoteric bugs that were specific to our layout engine.
Licensing our browser was a huge win for Spyglass. And it was a huge loss. We got a loud wake-up call when we tried to schedule our second conference for our OEM browser customers. Our customers told us they weren't coming because Microsoft was beating them up. The message became clear: We sold our browser technology to 120 companies, but one of them slaughtered the other 119."
I was in IE team on dev tools. We shipped every 6 months, while chrome shipped every month. In the last 2 months of 6 months release, we had feature code freeze. Even small bug fixes weren’t allowed. First month was planning. Our dev pace was slower than Chrome. Chrome shipped a lot more in 6 months than IE did.
Chrome had an insane testing suite that tested pixel perfect rendering and Perf benchmarks. Doing this on every pull request is just amazing.
IE had some work to do. I was surprised to learn that the E2E test results were hosted on some engineer’s dev machine in his office. We used to run tests on our machine before committing to source depot. IE CI/CD had a lot to desire.
My takeaway from IE vs Chrome was that Chrome had good leadership, they highly invested in all kinds of tooking to encode their security, UX, performance bars.
IE leadership was sometimes far away from the user experience. They didn’t care about the little big things.
It's worth observing here that Chrome was not just unusual in having access to a huge budget and highly experienced senior engineers, but also in the fact that it was the passion project of Larry Page. The Chrome team could take their time, because Page simply wanted to do a browser and always had, end of story. I worked at Google at the time and I recall vividly that Page/Brin never emailed the entire company in the way most CEOs do. They appeared at TGIFs but emailing the whole firm at once? They just didn't do it. With one exception (that I can recall at least): the day Chrome launched. Not only did Page email the whole firm but he sent a short, informal and clearly ecstatic note proclaiming that Chrome was "spectacular".
Schmidt opposed the idea the entire time, so Page and Brin just hired a bunch of browser engineers behind his back and funded what was basically a black project. Schmidt later stated he was basically forced to change his mind "because it was so good". In reality he was forced to because he'd been there before and it would have been self destructive to try to cancel an already running project the company founders were so in love with.
Remember, at the time Chrome launched it:
1. Only ran on Windows.
2. Couldn't print, amongst many other missing features.
3. Had no extensions and wouldn't for quite some time.
4. Had numerous page compatibility problems with many major websites that simply didn't work at all, due to its KHTML heritage, UA sniffing etc.
5. Had a pitch so complicated and developer centric you needed an entire comic book with the developers in it to try and explain why anyone should care.
Not surprisingly given the above, it had a brief usage spike as people tried it out and its usage then collapsed to nearly nothing, taking (iirc) years to rebuild to its initial launch spike level despite being heavily pushed via the google.com homepage.
Also, Chrome was entering a market with largely stagnant competitors, unlike the IE3 team, who were (or believed they were) fighting a successful, energized, passionate company that posed an existential threat to Microsoft's business. The IE team faced time pressure. When Chrome appeared there was Safari, which didn't care about the Windows market and was there mostly as a feature tick box for Apple's operating systems. The IE team was still disbanded at that point. Firefox was an inspiration but basically funded by Google anyway, and was struggling with tech debt.
I'd say Chrome 1.0 was competently executed but in any kind of normal company, with normal goals (like usage or profit), in which the project wasn't the passion project of an invulnerable CEO, they would absolutely have had to crunch like crazy and would then have certainly been cancelled or gone bankrupt despite that, due to the near total focus on engineering over all else.
It worked, in the end. I'm writing this from Chrome after all because Safari is inexplicably buggy even though I'm using a Mac, and with time they did get to add plenty of compelling features. Also being able to outspend their competitors meant taking control of HTML5 and putting other companies in a position where all their budget is taken by trying to keep up with whatever random features they threw into the spec. But anyway, the reason the Chrome team could live normal 9-5 lives is nothing to do with senior engineering leadership. To claim otherwise seems kinda unfair on everyone building new products who does not have a time/money budget set by a near-obsessed CEO who also happens to control the google.com homepage. A good example of a team it'd be unfair to was the Android team, who also had very experienced senior engineers with OS dev experience, but whose position was far more similar to that of the IE3 team. Android's creation was typified by enormously punishing hours and huge amounts of crunch.
So these big tech companies have a caste system. And no I don't mean the Indian caste system, which obviously has its own controversies. The caste system is really a form of social proof.
Did you go to MIT, Stanford, UW, Waterloo or CMU? Ok, you're in the club. You can join TI (Technical Infrastructure). Out of college you'll be L5 in 2-3 years (the same level an external hire with 10 years of experience will have). You will find yourself on the better projects with more promotion prospects.
This kind of premature promotion is to find the 1 in 20 of these people who are truly talented enough to continue getting promoted to L6-8+.
Source: https://blog.thirdyearmba.com/not-everyone-should-attend-col...
For the longest time, one of the advantages Google has had as a software house is that when you're an industry leader, deadlines are soft because all you're worried about is somebody playing catch up, not your need to catch up to somebody else. As the company has grown in size and scale, calcified a bit, and branched out into spaces where they aren't the leader, the culture around this sort of thing has changed. They are not, for example, the leader in Cloud, and the life of a Cloud SWE is markedly different than the life of an ads or artificial intelligence research SWE.
It’s independent of deadlines.
My impression was the sprint is the deadline, so it emphasizes to not have deadlines in favor of small incrementalism. Hence, if there is an actual deadline, sprints I think are exactly the wrong tool to help
To be sure, my main point is to disagree that sprints help hit deadlines. They might even hurt.
For example. I'm not sure if that failure mode is really changed via sprints. if you get 10 months in, and 15% left, nothing changes that it could still take a year. Further, the sprints discourage lifting your head up to unblock, design and plan that 15% before you actually start on it. So seems a bit waterfall like to feel incremental stuff was getting done, but you still underscored that last 15%, and sprints encourage you to realize that very late in the game.
I think a big flaw in scrum is error analysis of expected completion dates. Instead of compounding uncertainty across sprints, often that velocity is given no error bars and is linearly extrapolated months into the future (and in a perverse way increases estimate precision erroneously).
This of course implies that there's an end goal (so it's not surprising that there's a rough plan with so and so many milestones already laid out), but allows for moving that goal. Of course, as I vehemently argued in that comment, doing this by force in a top-to-bottom way, spending more time chasing this constantly moving end goal in planning session, than actually working on delivering something is a folly.
(Of course there are very turbulent situations where a small company/group fights for its own survival, pivots every second week to something else, throws out half of the existing stack every quarter, etc.. etc... but in that case the problem is not with "agile". The problem is trying to do something that has clearly no market traction without sufficient money and a sane business plan.)
A "sprint" is, almost by definition, a pace that's sustainable only for short periods. The fact that developers are expected to perform sprint after sprint endlessly, to view "sprint" as the default baseline pace, seems a ludicrous abuse of language.
And no, developers are not expected to be "in a sprint more or less at all times".
To the contrary -- in between each sprint, there's a review, a retrospective, often a weekend, then regrouping and feature analysis, planning poker, decision on which features to impement, and getting it up on the board.
That's the whole point. Instead of a long marathon without revision/reassessment/regrouping, it's a series of short sprints interspersed with revision/reassessment/regrouping. The metaphor here is the distance traveled, not the speed. Sprints are shorter distances, that's all.
Nobody has ever intended "sprint" to mean that engineers are going faster than in a marathon, anymore than "waterfall" means engineers are all tumbling down white water to their deaths at the bottom. :)
> And no, developers are not expected to be "in a sprint more or less at all times"
Again, perhaps this is your experience. In my experience, in every company I've worked for that uses sprints, the end of one sprint is separated from the start of the next by, at best, a few hours, and often less than that. Planning meetings generally take place during sprints.
And to point out that sprints may be separated by a weekend seems, at best, totally irrelevant, as in my working life, weekends are not part of working time. "You are in a constant sprint at work, but hey, you get to rest at the weekend" is not a compelling proposition to me.
"in between" is overstating things a bit. The current norm seems to be two week sprints and all these things are done at the beginning and end of them. To be honest, I personally do feel like this gives the feeling of 'sprinting' because it usually means at least 2-3 days of the sprint are 'wasted' on meetings and that counts for a lot when it's 2/10 or 3/10.
And a lot of the terminology around this kind of process are geared to give you a sense of urgency. Right back to "Extreme Programming".
Everywhere I've worked that did "agile" did it this way. The ending of a sprint is always the start of the next one; teams are always in a sprint. If that part of the process can't be changed or removed then one of the best things to do is decouple the sprint cadence from other events. Eg don't put demo, pointing, planning, and retro on the same day. Try to do pointing mid-sprint, if you know what's coming up, so that you're not cramming it in at the end. Don't release to staging/prod at sprint boundaries, do that mid-sprint. The worst is to clump all the meetings, distractions, and stresses together.
I think the best structure I ever had was 3wk "actual work" sprints and 1wk to address tech-debt and do planning.
"Track Star" and "Literature Major" are not stereotypes that I recall from my peers getting started in software, back then I didn't know many other computer nerds who had done more sports than my half-hearted JV swim and football, which is pretty weak. We for the most part had all been spending way too much time in front of the computer to be truly serious about athletics and literature.
But I'm old, and times change (which is a good thing).
Of course it would also be darkly funny if a bunch of literate athletes invaded the software business when it became lucrative/high-status and immediately started fogging up the windshield with a bunch of vague metaphors to obscure their lack of technicality. Who knows.
When sprinting, any bump in the road can make you stumble, losing the race. We need more focus on clearing the bumps out of the road before a sprint.
Perhaps it would've been more accurate to use something like 'unit' in education. Which is just a subdivision of time and effort roughly equal to a week or two.
Also, technical decisions should not come from the top. A leader should look at what something puts together and say "yea you covered your bases, go for it."
My current TL is older than me by a big gap but my experience on many technical things out-ways theirs and so they defer to me. Their experience on the social side of things is far better than mine and I always defer to them for planning and comms advice.
Basically: Age is a very poor proxy for how competent a leader is at running a team, making technical decisions, and many other factors that come to building large products. Selecting by age and putting the oldest person in change of a project is a horrible idea. Case in point: most governments are gerontocracy. How confident in the wise decision making powers of our political leadership?
I would argue it's agile if you release early&often to continuously incorporate feedback, even if you don't play Planning Poker in Scrum Sprint Planning every two weeks.
I would argue that isn't agile at all.
one of the strangest and most baffling things about the entire industry tbh. Like, would you ever expect a 25 year old guy to command a spaceship? Yet in software you have these weekly "I'm 40, is my life over" posts. In most disciplines people correctly acknowledge that there's a sweet spot of skill and experience that overlaps somewhere in your late 30s, 40s or even 50s, yet in software very often we recreate Lord of the Flies, leading to chaotic project management.
There is this constant infantilization of people where once you’re an adult you don’t think anyone younger than you is capable of anything. It’s a big problem that this has been creeping into how we treat people like children at continually older ages.
Nobody knows how to do things when they start doing them, and they won’t until they do start. Delaying this to an older age makes this harder not easier.
So the solution to avoid infantilizing them is to organize through scrum, standups and sprints? :P (which is where the discussion started)
That said, it's fair to say that a lot of young people are capable of far more than contemporary culture (or management) recognizes.
Okay, the exceptions: management failures. When them who should be doing their job are too fucking incompetent to pull their finger out of their arses. Years ago I worked at one place where they had 3 home-made frameworks floating around the company. A framework was clearly needed, management just dithered, so 3 different programmers just got on with it and did the necessary creation. Triple the work done, and an inevitable political war was brewing over which one would be used. And this was a medium sized company producing accounting software, not some inexperienced startup. Oh yes, I do have other stories like this... Crap management is a curse. It's always management IME. Fuckers seem to breed like rabbits too. Yes I am bitter.
> Circa Apollo 11 the average age of a NASA engineer was 28. In 2009 it was 47.
That has absolutely nothing to do with "treating people like children at continually older ages"
Circa Apollo 11, the average age of the American population was 29. Today it is 38.
In addition to that, NASA had its budget increase over 1000% between 1960 and 1965, so it had to hire a lot of new people for doing something nobody had done before. That is a very different situation than in 2009, when its (inflation adjusted) budget was around half the peak and had been slowly declining for almost 20 years. You don't hire a lot of people in that situation, so your workforce automatically ages.
Head of huge mission-critical project? Retired at forty? Nope.
I find this highly dubious because circa Apollo 11 the space program employed its largest workforce ever, including bazillions of mechanical engineers making nuts and bolts.
A more meaningful comparison would be what the average age of the managers and leadership are/were.
By 2009 the industry was old enough to have people close to retirement age who had studied it in college.
Isn't this a bit flimsy? Eventually, we'll treat all people younger as those who have room to grow -- isn't that to be expected? "like children" is relative.
I’m not talking about some vague concept of “leadership”. Most of the experienced engineers I worked with on Chrome weren’t even officially “leads”. They were individual contributors just like me.
I’m talking about the nitty gritty day to day details of writing robust reliable software. Class or function here? How should I test this? How should we detangle this spaghetti code? What order should we conquer this bug list in?
If you want to make a good software product it’s best to have people on your team who have made many software products before successfully.
That data point is from a 2006/2008 report^1; that data refers not only to NASA "engineers" but to all NASA "civil servants". It probably does not include the JPL as that is a NASA contractor, managed by Caltech. JPL employees are not civil servants.
After reading the 2006 report, as updated in 2008, I am having difficulty understanding how this single data point from 2006 is evidence of the "constant infantilization of people". Some further "evidence" would be appreciated to help me understand.
Below is how the report explains the age distribution of civil servants at NASA in 2006/2008. (This does not tell us what is the age distribution at NASA today. To get an idea of just how dated is this report, check out the quote the author pulls from the Strauss and Howe (2000) book titled Millennials Rising.^2)
"Even today, NASA has an extremely low attrition rate. With an average rate of 4.6% per year, the NASA workforce does not turn over very quickly.11 This rate is below NASAs own historical rate, far below the private sector rates, and even below those rates of other Federal Agencies.12
Most attrition comes from retirement-eligible employees. The attrition rate among Boomers in their forties is extremely low, about 1% per year and members of Generation X have about a 4% attrition rate. The Generation X attrition rate at NASA is lower than the Generation X attrition rate at all other Federal Agencies.
To fill critical positions, there has been a low level of full-time, permanent hiring at all times.13
Importantly, the demographics of this hiring have changed over time. Priority was given to fill critical positions to minimize gaps in core competencies, so the trend in hiring has been to hire older, more experienced workers who could best fill those gaps. This has meant that in 1993, NASA was hiring primarily members of the Boomer generation and in 2005 is still primarily hiring members of the Boomer generation.
1. http://web.archive.org/web/20091211095752if_/http://www.open...
2. "In obvious contrast, members of the Millennial generation tend to have starkly different views of employment and government.
Entry-level youths will be attracted to solid companies with career ladders and standardized pay and benefits. They will be less attracted to consulting, contracting, temping, freelancing, or new business startups. Millennials will be less inclined than Xers were at like age to take big career risks or turn their personal lives inside out to make more money.5"
Personally, I was a tech lead at Google pretty consistently from the ages of 26-35. I got better at it, and responsible for more, over time. It was a good learning experience for me and even when I was inexperienced at it, I was saving someone else some time.
My plan so far is to take every engineer who is local out to lunch individually to get to know them, and encourage them to use the yearly education/convention stipend to get us all at a convention together later this year.
Do not let your first project with a new company fail. You won't recover from that, even if it's not your fault in any way. Succeed and you will become known as a person who gets things done.
Also be a mentor to the other devs. But I assume you're already doing that if they hired you as a lead and based on your ideas.
Figuring out people's strengths, interests, and where they need to grow is key. You want to give people projects that are going to help them grow by pushing them a little bit out of their comfort zone, but not too much, because you also want them to succeed. Someone on the team needs to work on presentation skills? Giving a presentation to 10 people is a good opportunity to learn from mistakes. But if the audience is 100, maybe don't set them up for that kind of failure. Someone wants to grow into a TL role? Encourage them to host an intern. Etc.
You also need to understand people's career goals. You might be an (in Google terms) L5 TL with two other L5s on the team and a couple L3-4s. Who wants to get promoted on which timeline? Should the high-impact, interesting L5 project go to the L4 who wants to get promoted, or to the L5 who doesn't care about getting promoted but just wants the most interesting project?
A lot of that sounds like manager stuff, I know. When you're a TL, your manager is your partner as well as your boss, because the two of you are working together to keep the team happy, productive, and successful. And you'll both have information and perspective the other doesn't.
Google has a great viral slide deck about how to take credit for things as a TL. It works better visually but I'll try anyway. Basically, if the project is to deliver a big square, the TL's job is to cut differently shaped pieces out for teammates to do based on their skill, interest, what will be a good growth challenge for them, etc. Then, as a TL, you do whatever scraps are left over (imagine cutting a big circle, a rectangle, and a smaller square out of a square). So the IC work you do might seem like weird odds and ends, but if you get the whole thing done and everyone on the team was happy and productive, you succeeded as a TL.
It actually amazes me how much goes into writing quality code that is usable in production. I would be very surprised if any junior engineers could do it without messing up a bunch of stuff (which I certainly wouldn't fault them for as they're still learning!) You would need a good mentor if you wanted to avoid that I guess.
…that all this supposedly stable production code with tests and architecture is useless. because you throw away the stack entirely after 5-8 years, because the API has changed, because the tech is not fashionable, because the new SOC/PCI/Bale regulation mandates things that only exist in AWS.
Just hack the minimum together, speed of execution >> durability of the stack.
I blame Silicon Valley VC's for this attitude - if you have not invented Facebook by the age of 18 then you are done for.
That said, there are older people around in more senior roles and the way leaders act there is very structured but leaders are also expected to improvise when necessary.
It's somewhat amusing when you're dealing with those guys on some sort of technical collaboration. You might have a team from some big tech and then a bunch of "kids" in the room.
More like 30+.
On average, conscripts are basically useless for the first three years. Only those on extended contacts can be (somewhat) relied upon.
> Or leading a software project.
Software engineering units use 5+ years extended contracts in addition to mandatory 3 years. Plus very heavy selection.
Side note, sometimes I get “flashbacks” of my time in Israel and miss it. In those moments the US feels sorta like a surreal place detached from reality a bit too much. Silicon Valley/California is the worse for that.
Israel overall has a fascinating mix of different cultures from east and west (with no small amount of tension at times). Many of my assumptions about the world were shattered and your sense of history changes (for an American at least). I had an Austrian roommate and a Palestinian neighbor in the dorms. If you visit, definitely try to get off the beaten path, visit a Kibbutz, goto a Shabbat dinner, etc. Try and visit Jordan too!
Israeli's are generally a passionate lively people, but also serious and pragmatic. They can be... prickly too. It makes sense how Israel has so many startups and technology per capita -- lots of smart motivated people paired with discipline gained from IDF service.
Also, often times the only way to get that experience in the first place is to be put into the positions of leadership to develop your skills.
We're finally getting to the point where there's not much "new" each year or decade, so it's starting to slow down again.
I used to work with this person in his early 30ies and they were in charge of the infrastructure. This person started as a developer and then was tasked with managing infrastructure, while not having never actually worked as a sysadmin and/or having done operations work.
Well… after a while it became clear that the limitations of the infrastructure were a reflection of the limitations of this person’s knowledge and understanding of infrastructure.
Experience does matter.
Appeal to age runs deep in our species.
You can run a fraternity, a marching band, a 800+ member charitable organization project before 20.
Often at companies (And I presume in other situations as well), people are thrust into higher level positions purely because they happened to be in the right place at the right time and someone above them left.
Too many people/companies claiming to be "world class" or whatever when they are above average at best.
I have no knowledge of Lafayette (Not American) and no context or understanding what he did, so my default judgement is that his skill is exaggerated.
It's worth noting he had been trained in a French military academy for officers since 11, and was commissioned as an officer in the French Musketeers at 14.
Additionally he was extremely well connected in the French nobility and clearly had the expectation that men would follow him.
As for his leadership capabilities, Washington cited him in a letter to congress when he was still officially an adviser for rallying US troops during a retreat after being shot in the leg. His record is pretty good: https://en.wikipedia.org/wiki/Gilbert_du_Motier,_Marquis_de_...
Maybe this is true on a relative scale (E.g. good leadership skills for their age), but I don't believe it's true on an absolute scale and an absolute scale is the only useful scale in a professional environment.
I also believe that leadership skill is domain-specific, so having significant experience in your domain along with good leadership skills (Real skills, not from courses or workshops or whatever) does not at all seem feasible by the age of 20.
My current company is lead by someone with good leadership skills, and successfully managed a commercial team. Now he's trying to lead a company, and it is clear that he does not have the necessary experience to make the correct decisions.
Flight software is a fun role because they're the first person anyone asks when something goes wrong. "What's causing that sensor to glitch out, is it a bug?" "Uh no, probably not. Hey I'm just a software engineer, but is it possible the pyrowhatzit is actually melting right now?" "Oh crap"
I do think there are lots of advantages from experience, both on the technical side and with organising teams but I don’t think it’s totally crazy for young people to sometimes be very useful and productive. Plenty of the companies YC funds are founded/run by people in their (often early) 20’s and some end up being managed well and others poorly. If it were the case that young people so obviously weren’t able to do it, I would expect YC would have changed their behaviour by now.
And then people wont use it because it's bad and your company will go under, problem solved. Some other 20 year old (or 40 year old) flying by the seat of their pants who happens to be good at development will step in and build something that works.
Obviously if you're building medical device firmware, or aircraft control systems or whatever then it's a whole different story. But generally companies building that sort of thing do have a much more systematic and dedicated approach to quality. And there are industry regulations that enforce that.
- Sure, a senior might not use that NPM package coming from Zorglub89 on the internet, but then they’ll also execute slowly because of the hurdles of checking for these packages.
- Sure, a senior will perform external security audits regularly, but a lot of seniors are also in it for money or career and will be rogue.
IT has systemic leakage of PII.
Charles Darwin was in his early 20s, and the captain of the Beagle was only a few years older, when they blasted off to sea to do their surveys.
In fact, this idea that incompetent people have never built buildings before is just wrong. There are plenty of examples from history of unqualified people somehow being given the job of constructing something that then collapses killing dozens of people.
There is some safety critical software and I hope that that is written by experienced people. But basically all buildings are safety critical.
Although, I believe that info is now out-of-date and I don't want to engage in celebrity stalking behavior. Let him have his happiness. I honestly don't begrudge it.
I'm blessed down here to be sitting through stories about living the one life you have, right?
I find that observation interesting. I can actually tell, when reading about project failures, that no one with any real-world experience had a hand in it. Someone came up with a hare-brained idea, froze out anyone who would dare to say "yeah...but," and went full-throttle.
Genghis Khan was 20 when he started assembling his army. You can have leadership at any age. Some organisations such as the military bring in young people to directly be leaders. You need to look at people's ability, not their age.
What I'm saying is obviously that if you looked at merit, on average, software teams should be older than they are, not that it's physically impossible to have a good leader who is young.
What did he learn in those 20 years that made him Genghis Khan?
Us fossils think more before we do anything, because we ain't got all life, and we definitely want to keep it as simple as possible, as we don't want to be getting calls after dinner time - at 6PM :)
I'm not sure, I feel like on average there's a decrease of openness/neuroplasticity or call it whatever you want with age: people sometimes get set in their ways, choose approaches that worked for them in the past and will be less likely to jump into new technologies as often - having families and other life responsibilities (and having a better ability to balance life and work) will lead to a bit less exploration.
This doesn't apply to everyone, of course, and even then the premise isn't set in stone, but I'd say that you sometimes exchange the desire to jump into bleeding edge technology and innovative solutions for picking approaches that have minimized risks and are more likely to work out long term, a bit like: https://boringtechnology.club/
Not to say that either is better than the other, there is definitely a lot of merit in having experience and having worked on lots of systems in the past. I just wish that the industry itself didn't move ahead so fast and we focused more on the quality of what we have: e.g. more like PostgreSQL, rather than the new seasonal NoSQL database, or looking at React after a few months and finding it pretty different already.
Biases in hiring, of course, are likely to just make the conditions worse for everyone. Ideally, you'd have a mix of engineers of different seniority, that could successfully collaborate and learn from each other. Disclaimer: the biases in my own post might be construed as ageism in of itself, though I'm also kind of speaking of my own experience - as I gradually age, my focus shifts towards building rather than exploring.
Pretty common for someone to leave school at 16 and be done with their apprenticeship at 20.
e.g. James Monroe (18), John Marshall (20), Aaron Burr (20), Alexander Hamilton (21), and James Madison (25)
The Constitution was not ratified until nearly 15 years later.
Second, none of the people you listed signed the Declaration.
The average age of the Declaration signers was 41; only 3 were younger than 30.
If we're being VERY generous, we've consistently lived past 40 for the last 2,000 years.
So for 99.33% of human history the ONLY leaders we had were under 30.
That's not... that's not how statistics work work at all.
Life expectancy was 30 because half of all babies died, and on top of that childhood diseases took out a bunch more. Eliminating this has been the vast majority of life expectancy increase.
If you made it to puberty in antiquity, you were pretty likely to make it to 60 or so. Y'know... assuming you didn't live in an area the Romans or Mongols wanted.
* All I know is that humans used to produce a lot of babies because a lot of them would die, but my googling sucks
Until the middle of the 20th century, infant mortality was approximately 40–60% of the total mortality. Excluding child mortality, the average life expectancy during the 12th–19th centuries was approximately 55 years. If a medieval person survived childhood, they had about a 50% chance of living 50–55 years, instead of only 25–40 years.
Most people are in the office (when they are actually in the office, which isn't often these days), from 9ish to 5ish. I've worked at many companies that offered dinner at 7 to encourage people to stay late, but that only seems to have the effect of having people start later. No one really tracks hours as long as the work is getting done. Plenty of time I'll cut out of work around 2pm for something and then check in later in the evening for a couple hours.
General trend is people in their 20s work longer and later. Most people over 30 at any tech company I've worked at are out the door before 5. But also people over 30 tend to more reliably be in the office at or before 9.
If you come in at 9am, do work, have lunch, make coffee, work more, suffer meetings, work, chat at the water cooler, work again, and leave at 5pm, you're working 9-5.
In my experience, lots of engineers will show up far after 9 AM and leave well before they have reached a full day of work. Its a very privileged system that exists because it is so hard to hire engineers. At least for now.
Lots of people arrive before 8 but it's not the norm. 8am meetings --before COVID-- were always generally frowned upon.
For example at EPAM (big outsourcing company, badge tracked time spent in the building) and at LogMeIn as long as the sprints were "green" everything was fine.
Real software requires some degree of planning, and sprints seem to be more an attempt to avoid that planning. I don't mean to the level of gantt chart hell (I've experienced that as well).
Sprints, at least as they actually occur in the real world, seem to actively harm any large scale projects, and increase the overhead for long term projects if you can get them to fit.
the team should not pick a task until it's clear what to do and until it's broken down into something that they think/agree can be delivered in one iteration.
this is usually called refinement. (as the raw user requirements are transformed into a concrete design and then tasks)
http://tryqa.com/wp-content/uploads/2014/12/scrum-methodolog...
if something is so unclear that the design/planning itself requires prototyping something, then that can be added as a task for the sprint. then when it's done, on the next refinement the team is in a better position to find a good design.
And retrospectives were useless in the most literal way. The time spent every week going over "What worked well? What could have gone better?" did not materially improve the team's effectiveness.
If your point is that your team processes are sooo perfect and sooo amazing that there is nothing to criticise, review or change, I'll have a hard time believing that.
If your point is that no matter how much time you spend on these meetings, nothing changes, I'd argue that you need to spend even more time and energy on them on them as you clearly haven't figured out how to efficiently gather, analyse and act on self-reflection of you team processes. The retro itself might be the starting point of your thought process since it seems so "useless" and yet is absolutely essential if you don't want an external "manager" to do that job for you.
In response to this thread: https://threadreaderapp.com/thread/1426587396343099397.html
Well carpenters don't build houses by themselves. You might be talking about a framer, whose job is definitely important, but not really more important than most other of the trades needed to build a house. But actually by their late 20s a framer can have a decade of experience, more than enough to become a journeyman and frame with one or two assistants. It depends on when they apprenticed and became journeymen, where they learned the trade, and what their contracting and business ethics are.
> Would you drive cars designed and built by junior engineers?
Designers don't really build cars, but junior engineers are involved. Typically not leading themselves, though, as the handful of big car manufacturers can hire senior engineers to oversee them, and screwing up the launch of a car won't make it easy for you to work for one of the few competitors. People who make custom cars have probably been doing it for years as a hobby, and often aren't engineers at all.
In the non-software world, if you build something, there is a direct tangible result of that thing coming into existence. Like, if you build a cabinet, the worst case that happens is the shelves fall apart, so you don't need a whole lot of guarantees as a consumer. If you're building a car, there's a shit-ton of regulations (today, anyway) and potential lawsuits. If you're building a house, there's the code, there's 30 different specialized trades, all kinds of restrictions on who can do what and when and how, and a hundred government inspections.
But like in any trade, you can pass a test and still be a lying cheating piece of shit. (If you're a government contractor it's hard to tell if you're the former or incompetent) There is no magic spell or development lifecycle that stops shitty things from being shitty, or makes things automatically good. But sometimes there are regulations that enforce due diligence, and sometimes a contractor earns a good reputation through their results and word of mouth.
Sadly, in the software world, there are practically no regulations, no [serious] trade groups, no apprenticeships, no unions, no threat of class-actions, and very very rarely any substantive real-world consequence to shame a company into hiring competent workers. Bottom line: if you work somewhere and you are not satisfied or don't feel the work is challenging enough, get better and move on. The only way to escape monotony is to raise yourself up.
When someone says, "Wow, we worked nights and weekends, guzzled Mountain Dew, pulled 48 hour coding shifts, drained our mental health, and half of us got divorced, but the result was this kickass video game!!" it's not admirable--it's sad. That's just not how it's supposed to be done, people!
EDIT: This seemingly well-received comment seems to have ended up perma-locked to the bottom of the page. -weird!-
It's not just sad. It's often bullshit.
I don't believe for one second when people say "I worked 120-hour weeks for 6 months!" Simple math tells you this is a farce. Even 100-hour weeks is not sustainable, unless people want to claim they literally did nothing but wake-commute-work-lunch-work-commute-dinner-sleep for weeks on end. Not buying it.
The idea that you're living at the office and actually being productive is just laughable. It is absolutely not helpful except in brief emergency situations.
I didn't have many blocks like that, but those were some of the most productive (and personally fulfilling) times of my life. They made my career. Those allowed me to level up each time in a very significant way.
I also had long breaks after each of those -- they set me up to cruise for a while.
I did that before kids. I couldn't do that after kids. After kids, though, I have a depth of knowledge that makes me applicable for other types of productivity and work.
That mattered less in the days of one artifact software development (and still matters less in areas like video games where that is the case), but software development these days is a process and many projects are far more marathon than sprint.
It should give everybody pause, including software practitioners. A separate, but related pet-peeve is how these unsustainable heroics are often rewarded at work!! Boss: "Look at Chris over there--he stayed up until 4:30AM and fixed that ship-blocking bug. What a champ!" Chris gets a $1,000 spot bonus and now the rest of the team looks up to him as an example of good software development. Incredible but it happens almost everywhere!
Edit: Okay, I guess the kind of ageism he is suggesting isn't illegal in the US, but it is in the UK and is still generally considered unethical
I had my first "senior software engineer" title when I was 28, and that was after I'd only been writing code professionally for a few years (in my early 20s I had a campus coding job at my university, and then I was doing a lot of open source work through my mid 20s, but not sure I'd call any of that "professional"). At my most recent job, I saw most developers making it to the senior in their late 20s, and many even making it to "staff" (one level above senior at our shop) by 30, or soon after. That's ridiculous. In my mind, most people should be hard pressed to develop the experience to really be "senior" in something before they're in their mid to late 30s.
Now, I certainly don't mind (from the standpoint of prestige and salary) that I somehow ended up with the title of "principal software engineer" (one level above "staff") when I was 33, but... c'mon. When you've nearly tapped out your career ladder by the time you're 35 (unless you move to management), it feels like there's something not right there.
If you left the company you work for right now(other than to start your own company) you could find yourself as a staff engineer(one level below) somewhere with an accelerated path to the next level maybe, or in an equivalent role, although this is more difficult just because there are fewer positions and more filters to being hired.
His argument assumes you are aware of the youth bias, and is gently pushing against the ageism by pointing out that senior software engineers have a LOT of useful knowledge.
Where I work the young team are sticking hard to their contracted hours (nothing wrong with that). It's the seniors that pull the extra (but not mad) hours to get shit completed.
People with established careers in tech often change job through their established networks, and especially when they are highly sought after.
So it may very well be that the strongest senior candidates’ resumes never reach your inbox, while it’s more likely that strong junior candidates have no other option.
But I know plenty of people my age (my vintage? :D) with higher and lower seniority, similarly I know people older, and people with more time at the company in the industry with substantially lower seniority, and vice versa.
But also the companies I've worked at (FAANGs, so obviously large) don't treat "seniority" at the IC level as giving some kind of priority over lower seniority ICs. Obviously seniority factors into "how reasonable/accurate is their opinion" but that has never, in my experience, been a blanket override of lower "seniority".
The primary real difference is compensation, which is why companies like to get rid of senior engineers. I assume for a competent company they're doing a trade off "how much do they cost vs. how much value do they add", but obviously where we see this is always poorly managed "get rid of all the expensive people, WCGW" policies.
Chrome never needed to slay itself, because there was no customer expecting delivery. It literally couldn't be late because there was no set schedule. It was done when the engineers finished it.
Like many projects at Google. My experience in general is they don't do schedule-discipline well at all. And management there seems to think throwing ever more headcount at things will make them ship faster (it rarely does).
And there's very little accounting when promised dates are missed. Even by years. I worked on the software for Home Hub, and everything was supposed to get rewritten in Fuchsia, and they promised to be ready in like two quarters, almost immediately after we shipped it. They had unlimited headcount and the blessing of upper management, but failed schedule after schedule with no consequence. It took them another two and a half years.
Also I had a really hard time reading your comment with all the ellipses making it seem like it was just a huge sentence, that might just be me though.
I've never seen anything good from intense pressure from above—it barely even changes the timeline. You take the pressure away and you can still solid work in an orderly fashion.
> In light of all the responses, I really regret posting this tweet that mischaracterized reality:
> In fact: The IE3 team did not have an unusual rate of divorce.I know of no broken families and only one divorce during the IE3 project.
> Here’s my statement reflecting on this in greater depth: https://www.linkedin.com/pulse/my-recent-twitter-blow-up-had...
The Agile consultants somehow convinced a large segment of the industry that they discovered and/or invented the notion of working with users, of gathering feedback from them, of checking in with your teammates, etc. And they completely disregard the possibility that maybe --just maybe-- there are some developers who can get a metric shit-ton of work done without someone poking them repeatedly for status.
And they popularized the term "Cowboy Coder" as a reckless developer who does whatever the hell he wants and dares you to mess with him. When in fact, their so-called "cowboys" are simply the best developers in the team, who write great code and don't need a scrum-master to help them plan it. But the Agile methodology resists the notion of some developers simply being awesome at their job -- in Agile, you are good at your job by meeting your "points" for every sprint.
We have it a really good shot; we even hired a Certified Scrum Master. But after a while it seemed to me that we were just doing lots of tiny waterfalls. It was nothing for a developer to spend a whole sprint spinning their wheels and not making progress.
Long story short, 2 years later I took over the team, threw it all out, and set up a system based around Kanban and hands-on management. And suddenly we became productive again.
(Not saying Kanban is a solution, just that Agile is not)
I think the manifesto is great btw. It’s just that the formal “Agile” processes, such as the way Scrum is practiced, don’t implement it.
For me, there is a whole separate prioritisation and design process that runs ahead of the Kanban board. So by the time work arrives on the board, we have a pretty good idea of what we need to build.
The difference is that in waterfall, by definition, we would build what we’re told. But implementation of a design should instead be an ongoing conversation/negotiation between the high-level designer and the low-level implementor. And that can result in big changes to the high level design as problems, inefficiencies or new ideas come up. That is the “hands on” management I mentioned.
My way of working is heavily influenced by DDD. Design can only get you so far, and any process that imposes a top-down structure is IMO likely to fail.
Agile planning has used kanban-style stage notation for a long time. It’s just not always laid out in a grid.
Lots of awesome software was written without:
- Unit tests
- TDD
- Agile
- CI/CD
(to pick a few random practices). ... or in Agile terminology "there is some value in those set of practices".
The sad thing about Agile is that it reflects a certain naivety on behalf of its founders. That somehow we can encourage better software (and arguably corporate) practices through a set of principles (that aren't that bad). It's literally the road to hell is paved with good intentions.
Unit testing with 100% coverage is a red flag for me, someone spend insane amounts of time writing tests for useless shit.
Integration tests are the ones that determine whether stuff actually works, have more of them. There's no point in having a test to see if pushing a button produces the correct event if there is no integration test to see if pushing the button does what it's supposed to do in the backend.
There was plenty of very well written software in existence at that point. Large applications, operating systems, databases, games, embedded applications etc. etc.
That's not to say there's anything bad about unit tests just like there's nothing bad about the Agile principles. They don't prove your code works though, that's not really possible. A useful tool- sure.
It might be good to write them as you’re bringing up new code, but deleting the useless ones after that could be an improvement.
I've worked in more recent times on software that was used by millions of people, was extremely reliable, and didn't have a lot of unit tests. We did have other forms of automated testing though.
As long as there IS a process.
Agile is a way of protecting the coders from ad-hoc spec changes, because that's against The Process. The Process is a thing that management and stakeholders understand.
If there is no process, they can just turn up at Cowboy 1:s desk and request/demand/suggest their latest invention and expect it to be done.
even worse, now the specialist Agile consultants have themselves been replaced by McKinsey/PWC garbage
you can imagine how well one of these multi-million dollar "Agile Transformations" go
Having worked in government and big-co companies before: sadly, this is not a bogeyman trope, but reality. Including the printed binder, although it's called "spec sheet" or "tender document" (or whatever the correct english words for "Ausschreibungsunterlagen" and "Lastenheft" are).
The amount of "silos" and "leadership" involving themselves in petty fiefdom fights is astonishing - that is partially a reason why small startups are so much more efficient, they haven't had the time to develop layers and layers of middle management wanting to justify their existence, protecting budgets or establishing their authority. Government projects tend to be the worst target for such micromanager wannabe-king types, given that they can rarely be fired from their jobs for incompetence.
"You guys forked webkit which forked khtml, so you all had a nice leg up no?"
says:
"Yes. Just like IE started from Mosaic Spyglass. But a rendering engine (like WebKit/Spyglass) is not a browser. Certainly not a multi process, sandboxed browser. Chrome v1 was a 200 person year effort."
but, come on, much work was already done and they seem not to remember this.
All of the high functioning teams I’ve worked on didn’t have any kind of agile structure.
Agile can be done well, but more often than not it isn’t.
the development of something like Chrome isn't one of those project but say a banking website or a inventory management system could be