"Rule 11: Which database technology to choose:
Choose SQL when you need to do ad hoc queries and/or you need support for ACID and transactions. Otherwise choose no-SQL"
I think it should be the contrary: SQL by default, no-SQL if you have a specific need and know what you are doing.
I feel like the unstated caveat is "there will almost always come a time when you need to do ad hoc queries, and there will almost always come a time when you need transactions or the equivalent." Which translates to "use sql unless you are sure your don't and won't need to do ad hoc queries or transactions." Which... seems correct.
I feel like this is a case of "probably shouldn't have a default". SQL should likely be a default consideration but if you're going to say "time to build an app, let's spin up a (insert thing here) to store data" rather than "Let me take some time to consider what my data looks like and select a data persistence strategy accordingly" then you're probably going to wind up also writing a "how my team migrated from <x> to <y> because man did <x> not fit our use case at all" article.
It makes sense as a default because it will be the correct choice 99% of the time. Even when no-SQL is the better option it tends to be a better option for only part of the application.
Picking it as the default would make us wrong less often.
I question whether it's the "correct choice 99% of the time" or if, anecdotally, you're making the same kind of application and using technology you're comfortable with rather than considering alternatives.
> you're making the same kind of application and using technology you're comfortable with
To an extent yes, most apps (the ones that need a database anyway) are data oriented at their core, just a combination if input, storage and display. The data gets input here, it goes into rows, it gets displayed mixed with other data and displayed to someone else over there. Even when the specifics differ the data generally follows the same sorts of patterns because data is naturally relational and the combination of tables/rows/joins works really well nearly all the time.
> rather than considering alternatives.
The thing is, when you consider alternative you also have to consider the huge risks of what you don't know about them too. I've worked on one product where no-SQL seemed like the right choice, it was document oriented rather than the usual data oriented and it worked really well in our proof of concept. Problem is that the more we fleshed things out the more and more normal relational data we had and no-sql was making things more and more difficult and we started wishing we'd just stored the documents as a blob in an sql database.
So no, it's not just because I'm comfortable with it (although going with what you know has it's own merits), it really is the superior solution most of the time.
Not exactly, the fact that a NoSQL database doesn't enforce a data scheme doesn't mean you don't need a clear scheme which your app use, even if the schema is as simple as just take whatever the format that the frontend use.
Because if you don't your database essentially becomes a write-only vault since you don't have any idea of how your data is stored or was stored in the past.
To be completely frank, I'm seeing less and less reason to use traditional sql databases. MongoDB offers the ability to make sql queries and even has Acid transactions. Everything SQL can do, it does without slowing down when dealing with big data. The only thing it doesn't offer an efficient solution for is something SQL can't do either, and that's advanced search engine capabilities like Elasticsearch provides.
Some people will argue that PostGreSQL is better in certain ways, but the argument really always comes down to 2 factors. Are you going to hit the cost efficiency performance limits of traditional SQL servers, and do you require advanced searching capabilities like graph queries or synonym matching. Even if both answers are No, I'd still argue for Mongo because it makes it easier to distribute Acid compliant coppies of the data by region, providing backup redundancy as well as fast responses in multiple regions.
> MongoDB offers the ability to make sql queries and even has Acid transactions. Everything SQL can do, it does without slowing down when dealing with big data. The only thing it doesn't offer an efficient solution for is something SQL can't do either, and that's advanced search engine capabilities like Elasticsearch provides.
You seem to be looking at this solely from a perspective of what kind of queries you can run but there's a lot more to it than that. For example how do you model and maintain relational data, which I'd argue is most data? Does MongoDB have support for foreign keys or something like them these days? A quick Google brings up DBRefs but these seem very soft.
I don't want to sound too preachy but I find it often helps to assume the best of everyone. Most people aren't idiots, they just see things differently sometimes.
I thought about it a bit and I think that if you see something you disagree with or think is silly, usually that person either has different priorities to you (e.g. they might work in a document-centric company) or might just not have the same knowledge or experience. Either way, if you state your assumptions (in this case "relational data is important") and ask a question ("how does MongoDB handle this"), you should usually be able to trigger a respectful and productive discussion.
Of course sometimes there are just arseholes and trolls on the internet, in which case you can usually tell quickly and stop engaging.
I manage a team that's responsible for the Mongo DB that powers essentially the whole business. This is a 10 year old company that started right about when Mongo was trendy. After 10 years it's a nightmare to understand what's going on in that database.
And it's now extremely difficult to get off of it precisely because it doesn't have the schema and referential integrity and constraints that we need to be able to understand our data well enough to actually do the migration. We really want to switch to an RDBMS, but it's going to be risky and difficult.
You could say this is all bad engineering, and I guess that's true in a reductive sense. But it's like arguing that you don't need to climb with a safety rope because good climbers don't fall. Over 10 years and many engineers "bad" engineering happens.
I also believe that reasoning about data is hard, and you should therefore try to avoid doing it. You should do that hard thinking one time, and then rely on your database to enforce the rules until they need changing. Aka: Don't Make Me Think (About This Constantly).
If I believed in conspiracy theories I'd say that Mongo was one of the best vendor lock-in plays in tech. Mongo Corp is going to be profitable for a while because once you're down the Mongo rabbit hole it's a real pain to climb back out. But they'll host your database at least, so you don't also have to deal with that. I will give them credit for having a nice management UI.
But from my experience of the past few years I would never choose Mongo. For documents, Elasticsearch, or Postgres if you don't have too many. For relational data, a relational DB.
You can have well defined data and use Mongo. Those two things are not related. I worked at a place that used Postgres and put an object w/ 11k unique paths in a single JSONB column with no schema or documentation whatsoever.
Also, MongoDB queries for related records can be painful. This takes a while to realize, but definitely shows itself when you are working with more complex data.
This is probably my own fault, but I feel pressured to be constantly doing something towards programming. I feel like I should either be reading a book or starting a project.
I have 10+ programming books where I just finished reading one of them and I have way more unfinished projects than I could count.
It's reassuring to see the push-back against the 10x developer idea, I'm starting to feel less guilty now when I spend my free time NOT on programming.
Something that has also helped me out is picking a project to do, and ignoring everyone else's projects. I would always get pulled away with what I'm starting to work on because I see someone using a new technology or doing something unique. When I would see that I would change up my project because I felt it wasn't good enough or that it wouldn't make me a 10x developer. Now I'm just trying to focus on what makes me happy and what I find enjoyable to work on.
I want to ask though - the author works at Amazon and considers himself a 1x developer. What does that mean for everyone else who doesn't work at Amazon or a FAANG company? Is a 1x developer at a FAANG company a 10x developer elsewhere?
I don't think it's so much about practicing outside of work hours, it's more about being mindful about how you're going about what you're doing and evolving it to make more sense. If there's a trait I notice in mediocre developers it's more just that they have no interest in examining their own work habits. Its the guy that always reaches for the menu bar instead of learning keyboard shortcuts, or the guy that refuses to learn anything about functional programming because they want to stick to the basic java they learned in college.
> Its the guy that always reaches for the menu bar instead of learning keyboard shortcuts
I think judging someone based on their computer habits like being a command-line guy versus a GUI guy might be a risky thing. I'm a command-line guy through and through, but my newest boss comes from a different background and is very GUI-focused, and I think it would be easy to assume he's mediocre based on his choice of tools and such, but the results are more what matters.
That said, he seems like a pretty stubborn guy and I've definitely seen some warning signs on being resistant to change.
GUIs have had comprehensive keyboard shortcuts starting with the Apple Lisa and improving rapidly from there. Although they may have atrophied a bit in the man-bun Electron era.
A 1x developer at one of the tier 1 tech companies is...just a 1x developer - doesn't really matter where you're at.
Being a multiplier is not about just being technically proficient. It's about enabling your whole team to be more productive, and help getting to the right decisions, instead of decisions that might cost your team or coworkers huge amounts of extra work long term.
> Being a multiplier is not about just being technically proficient. It's about enabling your whole team to be more productive, and help getting to the right decisions, instead of decisions that might cost your team or coworkers huge amounts of extra work long term.
Thank you for this comment! I'll keep this in mind as I progress through my career. It's nice to know that it isn't just about being technical.
> "It's reassuring to see the push-back against the 10x developer idea, I'm starting to feel less guilty now when I spend my free time NOT on programming."
10x developers don't spend their free time programming, at least in my observation. They don't need to.
> "I want to ask though - the author works at Amazon and considers himself a 1x developer. "
A 1x developer would be an average (ok, fine, median) developer, no? About half are better and about half are worse. Compared to the bottom half of the statistical distribution, a 1x developer would by definition perform better.
> 10x developers don't spend their free time programming, at least in my observation. They don't need to.
Ah, I guess I need to read more about what people view as a 10x developer. I didn't mean to imply that a 10x developer spent all of their free time coding. I just meant that with companies, job descriptions, other dev, etc. talking about wanting a 10x developer I feel pressured to spend my free time programming, or at least doing something that would make me feel like I'm a worthy candidate.
> A 1x developer would be an average (ok, fine, median) developer, no? About half are better and about half are worse. Compared to the bottom half of the statistical distribution, a 1x developer would by definition perform better.
That makes sense. I guess what I'm trying to understand is, could you call yourself a 1x developer (or average) when working at a FAANG company? Doesn't working at a FAANG company imply that you are better than average, considering the status of these companies, their rigorous interview processes, and so on? I get the impression that FAANG only hires 10x developers, or at least developers that come across as 10x.
I apologize if I'm coming across argumentatively at all. I'm just trying to understand if the author is actually a 1x developer, or if they're a 1x developer at Amazon. Would a 1x developer at Amazon be a 10x developer elsewhere?
>Doesn't working at a FAANG company imply that you are better than average, considering the status of these companies, their rigorous interview processes, and so on?
No. Average devs are average devs everywhere. Amazon's scale is different, but it's not like the scope of an individual dev's problems are inherently different at FAANG than not. Not everyone will work on the most intellectually intense pieces of code at FAANG companies; in fact most don't.
"To replace out MediaWiki with a Java-based alternative (XWiki) ended up taking a total fo 24 dev-years over 4+ calendar years for the team, not counting the interruptions to pretty much every other team at Amazon as their pages were getting constantly migrated and un-migrated"
I would love to hear more about this. I'm guessing that's a cost of at least $4M? How was this approved? How did they allow it to continue for four years?
There's a roughly ~12,000-word postmortem document that took an additional 2+ months to produce after the fact, which the OP has lightly quoted or summarized from in his post (including what you quoted). It really is an impressively magnificent failure at scale, but there's nothing really fundamentally earth-shattering about how this project went so far off the rails. Mistakes were made, but IMO nobody was outrageously negligent.
The OP's assertion that it was primarily due to slavish devotion to InfoSec's insistence of getting off PHP-based MediaWiki, is incomplete and misleading. The team itself opted into the migration, and by their own admission in their own postmortem document, they wanted the opportunity to get off MediaWiki (killing two birds with one stone, both as a technology upgrade and as an InfoSec compliance thing), but they fundamentally vastly underappreciated the scale and complexity of the project (some top line #'s: ~4M total documents, 1.7M unique pages visited daily, 600K unique MAU, etc.). What probably doesn't come through in talking about this, is that the wiki is far from just a simple collection of text-based wiki pages in the standard sense; it serves more like something akin to an unholy abomination of a Wordpress-like platform with endless amounts of plugins and macros and templates, and gives you just enough programmability to be dangerous.
The primary reason it took 4+ years, was essentially down to going through multiple rounds of failed migration attempts, including failed attempts at producing automatic translations of wiki's from one platform to another (which proved to be incredibly complex, due to the nature of how customizable MediaWiki was and how many teams had gone and done so many interesting/advanced things with it, which was great... except it made automatic translation/migration near-impossible).
OP here: take another look at the first sentence of that post-mortem doc. I don't think it's misleading to say that this was primarily driven by InfoSec. Though I don't disagree that the purported benefits of XWiki technology were considered as maybe a secondary factor.
Fair enough (though executive summaries are by nature, lossy contextually).
I don't disagree that InfoSec was a driving force behind the project, and may have given it an unhelpful level of urgency (i.e. pushing for the team to make early decisions/plans too quickly, which anyways resulted in this banned PHP thing lasting 4+ years, seems counterproductive). But even if InfoSec was not a factor, the team knew that staying on MediaWiki was not sustainable, and some kind of migration would've happened eventually.
So I guess what I'm saying is, IMO the perceived pressure from the InfoSec mandate was poorly managed by this team, and ended up exacerbating the problem, but fundamentally the choice to migrate to a different wiki platforms was something the team wanted to do (just maybe on a different schedule or with different plans/priorities, in an alternate universe). Migrating off MediaWiki was not done against their will.
Keep in mind stories like the wiki one are anecdotal (meaning it's not representative of all projects), and in fact this is covered in both Patrick's tweet thread and Dan Luu's linked essay ( https://danluu.com/sounds-easy/ ).
So while they do their best to not have _every_ initiative go this way, large companies - even the mythical FAANGs - will inevitably have moments like this wiki debacle, and they need to be able to absorb them without material impact on the bottom line or having to fire a bunch of people for trying and failing.
Nobody makes fun of Coca-Cola for having 80k employees. "What do they have so many employees for? All they do are come up with combinations of sugar, water, and packaging. They don't even do the bottling!"
If I look at Coca-Cola's jobs page, I see a bunch of jobs that actually do have to exist. A short list, quoting from their page:
- Production operator: filling boxes, washing tanks, hook up and unload raw material delivery tankers
- Maintenance Technician: Overhaul and install new equipment, maintenance on equipment.
- CPS ID Laboratory Chemist: Ensure all raw and packaging materials and finished product comply with Company technical specifications including process water, ensure ingredients have all pertinent documentation before their final release.
Meanwhile, you look at Uber's jobs page and you see this (descriptions are quoting from their page)
- Business Development: We strengthen Uber’s position as the world’s leading mobility platform through creative and mutually beneficial commercial partnerships that unlock outsized value today and for many years to come.
- Data Science & Analytics: We transform data into magical experiences.
- Product: We create the vision for the future of urban mobility: deeply understanding our customers to solve their transportation needs with innovative technology.
Sure, Coca-Cola probably has some fat that can be trimmed. But at the end of the day you can't fire the guy testing if the coke water is poisonous, you can't do without someone to load boxes, you can't do without the mechanic. Uber, however, can clearly use substantially fewer people creating "creative partnerships" or "transforming magical experiences" or "creating the future of urban mobility".
Uber has around 30,000 employees to run a ridesharing business. (Didi, which does twice as many rides per day, has 10k.)
Coca-Cola produces 110 billion bottles and 3,900 different beverages around the world. They own their anchor bottler in North America and they produce syrup for pretty much every country in the world! They're so big they used to own Columbia Pictures.
Amazon's total all-in cost per dev is almost certainly >$300k per year, so more like >$7 million if that's an accurate number.
As far as how it gets approved, that's not enough money to really register at Amazon's scale. I've seen waste similar to that at companies much, much smaller than Amazon that goes entirely un-noticed.
> As far as how it gets approved, that's not enough money to really register at Amazon's scale. I've seen waste similar to that at companies much, much smaller than Amazon that goes entirely un-noticed.
Maybe I'm being dense, but this still doesn't register for me. If 4+ calendar years of work for a single team continues with no noticeable progress, then there's an organizational issue, no matter the size of the company.
Of course there is, but that's not the point. Every large organisation has organisational issues and nobody in the history of humanity has found a way of preventing them yet. The only thing you can do when the group sizes get large is to try and keep the problem under control relative to how bad it is at other large companies.
As far as I could tell, the "reason" given by the OP for this waste was attributed to Amazon's scale. Could you explain how company size and broken corporate structure are correlated? Or explain why 20+ person-years of engineering time wasted isn't a symptom of broken corporate structure?
That there is an organizational issue. Of course there is an organizational issue. There will always be organizational issues.
> Or explain why 20+ person-years of engineering time wasted isn't a symptom of broken corporate structure?
Oh, it's definitely an organizational issue here, that's just not the main point. If you're willing to call this a "broken corporate structure," then you should revise your opinion of every company with more than 50 employees downward sharply. This is a normal corporate structure, not a broken one.
> Could you explain how company size and broken corporate structure are correlated?
When there are enough people, you will always end up with conflicting incentives somewhere. A larger organization will have more of these. In this case, it seems to be a clear case of competing priorities: IT wants to secure systems, and developers want to be maximally productive. I'm sure some folks in IT view Amazon paying ~$7M as a fair cost to remove known vulnerable tools from their infrastructure.
It's unlikely that this went entirely unnoticed for 4 years, and I would guess that when the problem was understood, someone did the math on staying the course, versus starting over or reversing course.
And after all the internal calculations were complete (which factor in way more than technical effort by a small dev team), they intentionally stayed the course.
This is probably an extreme example because an internal wiki that is used company-wide will have an incredibly complex and hairy stakeholder matrix (both business and technical), which means consensus is very challenging.
At some point the cost of the meetings required to work out a solution (both in time spent, and in time not spent on core work by the stakeholders) probably exceeds the cost of just letting a small team brute-force their way through a bad solution.
Cost here isn't just money, it's focus, morale, disruption, conflict, risk, etc..
Keep in mind that you have the benefit of hindsight, and the comfort of looking at it from the outside, with a very incomplete picture of all the constraints and pressures at play.
But having worked in and around these kinds of teams and companies for most of my 25-year career, I can tell you that it's "often", in my opinion/experience.
It's pretty easy to have a project look like progress is being made in the moment, especially when presenting to the director+ level, where a manager is presenting on 4-5 different projects. It's even easier with projects that aren't important or highly-visible (as internal projects tend to be).
>that's not enough money to really register at Amazon's scale.
This viewpoint doesn't really match up with how enterprises operate.
It's possible to function at amazon's scale without meticulous accounting and financial operations. The reason for this is that is extremely easy for wasteful spending to propagate throughout the enterprise if unchecked.
Waste only appears after a project fails...it's easy to point out waste after the fact, but it's downright impossible to call it out as it's happening.
I don't understand why are corporations obsessed with decommissioning wikis.
When I was at Red Hat, they tried to decommission local country wiki in favor of their company-wide wiki (Mojo, absolute shit by the way).
They tried for about 2 years, then finally somebody said "what the fuck are we doing" and the migration was stopped. I believe the banner "Decommissioning soon" still hangs there.
What happens is that different teams build out their own wikis , or come in via acquisition). The company then ends up with a dozen of them, and re-orgs occur and a single team now has two wikis, and people wonder why the information isn't centralized. Everyone agrees it will be great to have a singe company wide wiki and the project is born.
Usually, someone saw a cool feature they wanted and everything moved to that. So often the main purpose of storing information gets lost to flashy new graphics.
Finding the right information is already difficult and a time-suck. Adding an extra place to look (and search interface, etc) for no extra value just makes it suck more. Plus there's all the TCO reasons - licensing costs, extra servers, extra maintenance, etc etc. You could also look at it as "Don't Repeat Yourself" writ large.
That's the famous w.amazon.com internal wiki that is basically the intranet portal for all of Amazon. I worked at AWS from 2016-2019 as a principal engineer. They were trying to deprecate w.amazon.com for the entire 3+ years I worked there, and were still trying when I left in early 2019.
I can tell you that Amazon is pretty great in most ways, but they have a lot of really old school tools. For example, they still use majordomo to manage hundreds of thousands of email lists. They've customized and extended it in so many ways that it probably looks nothing like open source majordomo, but at it's core, it's still majordomo. They just wrapped 1990s majordomo CLI tool with a 1990s static HTML page that authenticates you with oauth and lets you create and manage email distribution lists.
So many tools at Amazon are like that. But they actually function amazingly well once you adapt to their 1990s->early 2000s quirks.
One comment I'll make is this: every environment will have preferred "paved" roads - use X language/toolchain and Y relational database, Z cloud/metal provider. Ultimately these details, other than X and a subset of Y, shouldn't matter if you build the right abstractions. And by "the right abstractions" I mean you should just be able to declare something like this:
relational_database:
mydb:
size: 100GB
readers:
- auditservice
readwriters:
- application1
- application2
Very few organisations really count the cost of things like this internally. And it would have been quoted as "relatively simple" in the beginning; just migrate a wiki from one piece of external software to another, how hard can it be?
("how hard can it be" should be on your Words That Prefigure Expensive Disasters list. It's the business equivalent of "hold my beer and watch this")
Re: big company vs small -- Small companies fail all the time; projects like this pare more prevalent at big companies because it doesn't (always at least) kill them.
This is the most concise, honest summary of "agile" I've ever come across. Well put.
The amount of person-hours spent bikeshedding about various sundry "agile" procedural details is absolutely breathtaking. A perpetual, real-life Dilbert punchline taken seriously by armies of *Managers.
Well that's pretty naive. I've worked with some pretty good teams that wouldn't work any other way. I suspect you've only worked at places that abused agile as described here... https://ronjeffries.com/articles/language-of-hatred/
No, I've worked in places where it works just fine.
The point is that, at the end of the day, it boils down elaborate processes to break things up into two-week chunks of work. That's it. That's the bit I thought was a concise, excellent summary.
Sometimes, for certain flavors of apps and tech and teams, that model works splendidly. Sometimes, it is silly administrative window dressing that is completely disconnected from the reality of what the team is doing. In my experience, it's usually the latter -- and the teams work just fine _in spite_ of the fact that everyone is pretending they are doing "scrum" or "agile".
I'd say what is naive is the belief that such a closely scripted, narrowly defined workflow is a one-sized-fits-all solution to optimizing teams under all circumstances and contexts.
"Elaborate processes" and "closely scripted, narrowly defined workflow" aren't adjectives I'd ever use for agile done well. And I've been doing it since we were allowed to call it eXtreme Programming. There's lots of "Dark Scrum" out there. Sounds like those are your experiences. They're not mine.
Agile is the opposite of "closely scripted, narrowly defined workflow is a one-sized-fits-all solution to optimizing teams under all circumstances and contexts." You're thinking more of Scrum?
> Rule 20: When somebody says Agile, push for Kanban, not Scrum... ...Scrum can easily mean that you’ll get pressured to work extra hours to complete something within that arbitary two-week horizon.
This is very true. I've worked for over 12 years in the bay area in different software engineering teams at startups and found that scrum just leads to burnout and developer unhappiness and encourages team members to just do the minimum 'slap it together till it works' solution without thinking long-term on codebase stability, architecture and maintainability. By far the best development process that leads to high developer happiness, engagement, productivity and empowers them to go the extra mile to go above and beyond, and produce work that acts as a force-multiplier across the team, is what the author describes here as 'Kanban', also known as eXtreme programming. Most people from Pivotal Labs or Carbon Five or from a startup that adopted their process would recognize what the author describes as 'Kanban'.
To be clear: XP and Kanban are different things. XP has prescribed engineering practices, most forcefully that development should be done via pair programming for continuous code review. Kanban prescribes no engineering practices and could be used in lots of non-engineering contexts (e.g., your marketing team could take all of their tasks, put them in a prioritized backlog, then track the progression of those tasks across Todo/Doing/Done/Blocked and that would still be Kanban). Kanban is great for teams in maintenance mode with a steady in/out of smaller tasks in their backlogs, but it's not great for helping your customers get an idea of when they might see a new product or feature.
I do find it odd that people describe Scrum as "leading to burnout" or a "death march", and I'm guessing most people who do either have not worked in waterfall IT projects that preceded widespread Agile or they're part of "Agile" teams that do waterfall development in two-week chunks with daily standups. (Maybe both.)
Scrum practiced well brings the essence of small-town democracy into the workplace. You have to work a late night the day before sprint release? You were in the room when the team agreed to the body of work that would be committed for delivery in this sprint. You just slapped it together until it works? You'll get to accommodate 0-point bugs in a future sprint, and perhaps you can have a conversation in your team's retrospective about why velocity went down that week. (Speaking of: how many other professions get to have a candid conversation with management about what's going well and not going well on a regular basis? Not many, it's a real privilege!) There are certainly deviations from this, but in my experience Scrum teams' problems are generally of their own making, and many of those problems are refined away over time as teams grow and better define their norms.
> You have to work a late night the day before sprint release? You were in the room when the team agreed to the body of work that would be committed for delivery in this sprint.
Fuck that. The fact that my estimate does not work out as expected should not be a reason to work late nights just to get it done.
That’s exactly the death march that you were saying Scrum is not.
> I'm guessing most people who do either have not worked in waterfall IT projects that preceded widespread Agile or they're part of "Agile" teams that do waterfall development in two-week chunks with daily standups.
I haven’t come into an organization in the past 15 or so years which wasn’t using _some_ form of Agile (generally Scrum). It’s fairly likely anyone who has started their career in software within that timeframe may never have experienced how things were done in the past.
That said, there is certainly always room to improve, which is a critical piece I see teams often miss in Scrum. The two-week cycle isn’t just about planning and doing whatever it takes to hit the commitment. It’s about a) the business having a cycle they can plan to if priorities change and b) the team having a regular feedback loop they can use to help understand where they are doing well and where they aren’t.
Missing a sprint commitment is fine. Missing the commitment for multiple sprints in a row means something is going wrong. This is an opportunity to learn and improve, and the sprint retrospective at the end is as important if not more so than the planning meetings.
And then make time in the sprint to implement improvements in the process, tech, whatever is needed. We use 20% of the sprint time as a rule on this, and move that up and down periodically as needed.
> You have to work a late night the day before sprint release? You were in the room when the team agreed to the body of work that would be committed for delivery in this sprint.
This can get complicated depending on the team dynamics and upper management. Sometimes there are pressures that cause the team to overcommit (throw lower estimates, giving the illusion that things can be done within the 2 weeks).
Overall, I think it kind of depends on the product you're building. If it's some SaaS product in the modern world of CI/CD, it doesn't really make sense to hold everything up for 2 weeks and then release. If new things are being continuously deployed/delivered, then value is being delivered faster and the business is achieving goals faster, learning faster, getting returns faster, rather than having to wait 2 weeks at a time. This in turn makes your business more 'agile', and all the productivity boosts, developer empowerment and happiness are great side benefit of the iterative process.
> And what I have found is that most – say, 90%, of what I learn at one job is completely useless for the next one.
Then the problem isn't with what's being learned. The problem is that the author lacks a framework for generalizing and internalizing the lessons learned.
Letting 90% of lessons learned on the job go to waste later in life is going to lead to a very difficult career path.
Later...
> Compounding is a pretty important concept that shows up in compound interest, in Moore’s Law, all over the place. It’s about virtuous cycles. And so in the limited flexible time that I have, I think the rule of thumb is to focus on things that could trigger a virtuous cycle.
In other words, focus on activities that can capture more value from the 90% of wasted lessons.
Writing, both publicly and privately, is an excellent way to do that. It seems the author may have an inkling but isn't saying it. Given there are only two posts on the blog, this could be the author's attempt to test the idea.
> So I’m going to try to bootstrap my software engineering longbeard wisdom in the following manner:
> 1) Write out my inane thoughts on some software engineering topics.
> 2) Share out my thoughts to people smarter than me and invite vicious critique.
> 3) Update based on #2.
> 4) Attempt to come up with a methodology for finding and prioritizing useful information to read about software engineering, or reflections based on new projects, and integrating into #1.
OP here. You're spot on. Both in calling out that this is a solvable problem (not a fact of nature) and that writing is probably a pretty good way to get started. That was definitely the idea with putting up the blog.
I came up with the 90% number not because I have any real data on this, but as a way to provoke myself to challenge some assumptions. Earlier on in my career, it was easier to tell myself the story that everything I learned, all the hours I spent doing stuff, were all part of a bigger narrative. That it would all build upon itself in a one-directional way. Even if I forgot specific facts, I'd still always be learning and growing in one way or another. I'd be developing critical thinking, learning how to learn, moving to higher levels of abstraction, pruning out useless knowledge and strengthening core insights. That kind of thing.
That was actually a pretty useful mentality, and still is in a lot of ways. It gave me the confidence to do a bunch of career changes (like I think I mentioned in that section of the blog) because I did believe that I was drawing lessons from each successive career area to the next. And there was a lot of truth in that.
However.
At the end of the day, as a developer, I'm certainly not doing Leetcode or Kaggle all day. The majority of what I've spent my time learning has been very specific knowledge: learning the components and business logic in specific systems, getting comfortable with internal tools and processes, getting to become very familiar with some subset of all the company code, working with clients and dependent teams and internal customers. I do believe that being a tech giant can make the situation worse in that regard since the specific problems tend to be so narrow. But my hunch is that it's still the norm for developers.
I'll put things in a different perspective. According to a lot of studies, doctors get worse at their jobs on average over time (link: https://hbr.org/2017/05/do-doctors-get-worse-as-they-get-old...). Most of what they learn on a day-to-day basis is very specific, time-bound knowledge (specific patient info, office info) rather than general-purpose lessons about medicine. By going for the 90% number I was trying to push myself to consider that that sort of effect is the norm (in programming and elsewhere) in contrast to my earlier notions about "constant generalization."
I think this number can be changed but like you mention, it requires an amount of deliberate effort like writing that just hasn't been baked into my usual routines.
Congratulations. You are still getting paid the same.
Boosts in productivity need to come with boosts in pay, otherwise the logical thing to do is to scale back your effort to a point where the amount you get done matches the amount you get paid for.
There is a balance though. The company I work for is stable, but money is always tight. That means raises are few and far between.
Other factors balance that out and make it a reasonable place for me to work, but being aware of the fact that "exceeds expectations" does not lead to more money is important and I'm sure not unique to my situation.
I'm happy to go above and beyond, but I'm also aware that it's unlikely to be rewarded and take that into account in my decisions.
switching jobs is a promise of productivity. giving an individual company more productivity for free is bullshit -- get your comp adjusted as frequently as possible.
Programming is a marathon, not a sprint. That will catch up on you some day. Plus, personally, it just makes life hell. The day passes faster when you get into it and those things prevent me from getting into it (not true of everyone from what I've observed)
The point I was trying (perhaps poorly) to make is also along the lines of "marathon, not a sprint". Yes, do your job. But find the healthy balance where you aren't killing yourself for results that aren't appreciated.
Work at a pace that you can sustain for years on end. That goes both ways. Don't overwork yourself to the point of burnout. But also don't underwork yourself to the point that you are unemployable should circumstances change.
Shockingly, some people feel good when they do great work and have a positive impact. Often times it even results in other beneficial outcomes in their life.
If you are an independent service worker yeah, I understand, go the extra mile with your customers, it is good for business. But if you are drone #139098123 in generic corporation X, you should not give a fuck on your reputation as long as you are doing your work. If they dump you, you go and get another job, there is a big world out there.
> you should not give a fuck on your reputation as long as you are doing your work
But we're talking about reputation based on the quality/quantity of work you do.
I think there's a difference between taking pride in your work, and breaking your back for your employer. I think the former is what's being advocated for in this thread.
Also, if you feel like you're drone #139098123 in a soul sucking abyss, and can't be bothered to be interested in the activity you spend a majority of your waking hours supposedly doing in this short life, then I encourage you to look for something better. I know all too well that it's easier said than done, but it's better to start while you still have the soul sucking job instead of after they "dump you."
If you think checking reddit or HN at work is a cardinal sin, be my guest and run yourself to the ground doing 80 hours a week with no respite, ignoring that many many studies place peak cognitive performance at 4 hours a day at best,be a "10x" engineer and get promoted.Unless you are laid off, but that rarely happens so dont worry.
This! We average at most 4 hours of concentration a day if we're not interrupted too much. More than that every day of the week leads to burnout. Not worth it even for big bucks because it's your health down the line. $ hours of good brain time is a good deal for the company. The rest is administrative stuff and whatever.
I think all of us end on HN/Reddit (and which is the biggest time drain to me) is to learn stuff. It's not a bad craving to be honest but it is a bit of a black hole. I did turn the noprocrast on at times to get away from it.
Yes! The one you created.
If you're already working 4-5hours a day (as in actual working) you are giving all to the company. If you answer silly mails or check Reddit or whatever the other 3 hours is actually not a big deal and not a big dip into your productivity. Not a black hole by any means.
If you think otherwise you are not only being "dumb" (compared to the "street-smart company"), you are being an economical irrational agent, so you will naturally be taken advantage of and get worst (not better) returns (not only money, things, like health, free time, meeting a SO, raising a family) in the long term.
The fact that you willfully go to that extreme only shows how toxic is the Calvinistic worldview implanted in many people in the anglo western world and how companies ruthlessly exploit it.
Here's the post I replied to below, it said nothing about self-respect. You're the one who brought that up and still haven't explained how compensation factors into your "best work" / "self-respect" chain. Please, do share.
-------------
> Congratulations, you are now 3-10x developer.
Congratulations. You are still getting paid the same.
Boosts in productivity need to come with boosts in pay, otherwise the logical thing to do is to scale back your effort to a point where the amount you get done matches the amount you get paid for.
------------
To which I said, "exactly! if you're taking home the same salary whether you're creating massive value for the company, why bother?"
---------------------
So, if someone generates 10x more value than the person next to them, you think they should both be paid the same (while the company reaps the immense profits) and that nobody should complain about the situation because of their "self-respect"? Wild.
On HN, please omit rude swipes like "What are you on about?", "Please, do share," and "So if someone X, you think they should Y, and nobody should complain because 'Z'? Wild." Even if you're talking to a mod, you still need to follow the rules. I also need to, and you and anyone else are welcome to point it out when I slip.
that's not what happened. if you click the link you included, your "self-respect?" comment isn't on that thread at all. because it was a reply to my comment. you're intentionally misrepresenting what happened.
let me point out how you "slipped" and took a "rude swipe" - you don't play by your own rules.
i made a post, you replied to me just saying "self-respect?" implying that i had none.
how can you just drop insulting comments like that on people who are just participating in conversation? two words, no explanation, just plain rude.
Isn't your "self-respect?" comment in bad-faith, given your own rules?
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
"Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."
"Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Comments should get more thoughtful and substantive, not less, as a topic gets more divisive."
From the New Yorker profile of you:
"They treat their community like an encounter group or Esalen workshop; often, they correspond with individual Hacker News readers over e-mail, coaching and encouraging them in long, heartfelt exchanges."
Is that just BS? What was encouraging or heartfelt about your response to me?
If I work for a company and I'm earning them millions of dollars, you're saying that I don't deserve to be compensated proportionally, I should just give them my time and effort because of "self-respect"?
This explains why you always silence my replies on the Who's Hiring posts. If you truly think that people should work for 'self-respect', no wonder you hate it when I ask that companies post about their hiring requirements: length of process, type of interviews, projects and whether they're paid, etc.
Obviously you think we should all do those things for free because of our "self-respect". You must be rich AF already to have that kind of attitude.
> If I work for a company and I'm earning them millions of dollars, you're saying that I don't deserve to be compensated proportionally, I should just give them my time and effort because of "self-respect"?
Companies offer compensation based on a combination of the possible alternatives for that individual and cultural norms. If they know you can't get more elsewhere and the given amount is not vastly outside of the accepted norms (e.g. such that leadership feels morally satisfied and the company isn't at risk of harm due to a possible societal backlash), why would they offer you more?
Of course, some companies care about norms more than others. And I don't think it is ever the primary factor.
The link addresses the "If they know you can't get more elsewhere" portion of what you posted, but I didn't respond substantially to the rest. Thanks for the chance to expand.
> "at risk of harm due to a possible societal backlash"
Fear of backlash over paying too little should not be a motivation for compensation. Trying to push it as low as you can without actually sparking dissent, internally or externally, is a cruel game.
I'm into the idea of worker co-ops, so I'm not starting from an assumption that the purpose of a business is to maximize profits for shareholders. Sure, the business might profit less if it pays its employees more, to me a business IS its employees, not a separate entity. If the employees create even more value for the company as a whole, paying them more is a cause for celebration.
If the amount of value you provide increases in a meaningful way, so should your compensation. Instead, on salary we provide unpaid overtime in times of need and enjoy a flat-line of compensation even if we create a new product, invention, or process that massively increases company value.
Bonuses, equity compensation, etc can and are gamed by companies to pay as little as possible without "fear of backlash," like you said. (Cliffs, golden handcuffs, dilution, preferred shares, etc).
Theoretically a salary should be desirable because it de-risks the downside: what if you're put on an under-performing team, or your product launch flops? NBD, because you're on salary, right?
Likely you'll just be fired anyway - you can be fired anytime without cause (in CA anyhow, since we're at-will).
So, salaried positions result in what the OP I was replying to said - "the logical thing to do is to scale back your effort to a point where the amount you get done matches the amount you get paid for".
That DOES seem logical to me. And undesirable. We want people to dial their effort up, right? How do we build compensation and hiring systems that reward people who can add value? As it stands we're leaving a lot of human potential untapped - by design!
I don't think those things. If you're curious about what I meant, I'd of course be happy to share. But this comment and your others are making me feel like that might not be a good idea to try right now.
Yes it’s a complex emotive topic with lots of overlapping discussion and with terms like “self respect” meaning different things to different people.
The deeper into the thread the harder it is to make a point as I don’t even know who I’m answering and what they meant and what points of their comment ancestors they are answering to!
that's on me, looks like it was below the fold and is still there for now. but you're likely about to send it to the bottom for being off-topic, like you did last month. i've posted the same thing for 3 or so months in a row and there haven't been any changes. it's not even like you have to do anything other than say, "Please include some of this info".
My issue is not "with engineers being able to compare processes between companies", it's with you (or any user) hijacking the job board with meta opinions about how the job board should be organized. Meta discussion all too easily takes over a thread and is particularly off topic in Who Is Hiring, which is a specialized context and not the usual open discussion. There's plenty of opportunity for freewheeling discussion elsewhere on the site.
Lots of people have strong opinions about how the hiring threads should work, because people have strong feelings about hiring in general. The job board itself is not a good place to argue about those; it's off topic, adds noise and makes it less useful for its purpose. If one user is allowed to do it, many others will certainly follow, so this isn't just about one comment.
I explained to you last month under what circumstances we'd consider making the kind of changes you're asking for; I also explained why that sort of meta comment is off topic and not allowed in the thread (https://news.ycombinator.com/item?id=22755576). To show up the next month and do the same thing again starts to not be cool; please don't do that any more.
I've thought about this as well. If you have flow for ~6 hrs a day with ~2 hrs a day of buffer time for meetings, lunch, coffee...etc. You'd be in the top third of software developers. Anecdotal for sure but I'd love to see a study on this.
With rule #2, (knowledge not transferring), that's always a sign you're not working somewhere good, or you're in a role that will stunt your growth. You really should be able to transfer a lot of what you learn. If you're stuck with a bunch of proprietary gunk that does the same thing as open source, but worse, good engineering management knows to replace that stuff because it will inevitably drive talent away. Or at the very least rotate people through those roles. I know I've left jobs where I've been stuck maintaining legacy systems while the rest of the company moved on to open standards because if you do that for years it's like slow career suicide.
> Python and Ruby seem to me to be pretty similar in that they’re scripting languages and dynamically typed and seemed like the greatest thing in the 00’s. You use them when speed is more important than legibility or debugging.
I'd say you pick them when productivity and time to market is important. I personally find dynamic languages far more legible (unless you're doing metaprogramming-heavy stuff).
> Haskell or Erlang maybe I would use if I were doing something that required a very elegant or mathematical functional approach without a lot of business logic.
I think it's a mistake to throw these two into the same bag. I'd say Haskell is functional and comes from academia. Erlang is concurrent (with functional aspects) and comes from engineering background. You'd want to pick Erlang if you want to build scalable backend systems.
> my guidelines for JS are:
> Try to push as much logic as possible to the server. If the front end weren’t super complex, I would consider something like Phoenix instead which actually pushes everything to the server.
Phoenix is a web framework for Elixir and Elixir is a Ruby-like syntax on top of the amazing Erlang VM, so this kind of contradicts the suggestion above. Either way, Phoenix LiveView might be a game changer when it's applicable and for people who don't find the whole JS thing very exciting.
People overrate the elegance and readability of languages. You can write elegant and inelegant Java. I've seen python code that is totally unmaintainable and python code that's some of the most elegant out there. You can find Rails code that is some of the most indecipherable spaghetti out there despite Ruby being such an elegant language (the project had Fat Controllers, Fat Views and Fat Stored Procedures...yikes). There's a lot of elegant C code out there then there's C code where you don't wanna touch anything because you're not sure what anything does.
I think the general rule of thumb for languages is pick whichever language has the best community, learning resources and packages for your project.
For example R excels at analyzing data because of the wealth of packages from industry and academia for analyzing data and the tutorials dedicated to statistical analysis in R. Python excels at high performance data driven products because of the wealth of packages for ML, scientific computing, etc and the wealth of resources on doing these things in python.
The exception to this is JS and your point about Phoenix LiveView. Potentially it could be better to pick a single language for frontend and backend to limit context switching while developing frontend and backend.
I haven't used Clojure or Haskell yet so I don't know what they excel at. I also haven't dived into Erlang and Go enough to know which situations either is better for scalable backends.
> People overrate the elegance and readability of languages. You can write elegant and inelegant Java.
It's not what you can write, it's what the next guy can write.
You can write elegant Perl. But the language isn't suited to that. The next guy is going to use a more typical write-only style of Perl. Extreme example, but you take my point.
I think I was unclear. I meant that the exception to picking a language based on community, resources and modules are JS and Phoenix Liveview where there is an additional benefit of using a single language for frontend and backend. In these two examples you might forego using a separate language for frontend and backend (that could have a better community, resources or modules for what you are building) because you can use the same language for both (which offers the unique advantage of having to use and learn less tools for a fullstack app).
"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" -Brian Kernighan
Over time I've come to appreciate this sentiment. Banging out clever code super fast isn't that important... Spending some time up front thinking about types and architecture pays off in the long run. Especially for server side code. Far from being annoying, error messages from the compiler make me feel warm and fuzzy inside.
On the other hand, for quickly prototyping user interfaces, some "stream of consciousness" Javascript might just be good enough.
I very much like this quote. Used to work with a team of contractors out of Eastern Europe. They were exceptional programmers but wrote code using obscure language features and in such an odd way that now that they are gone, every time someone has to debug some of their code its a very frustrating process. There are definitely times to use 'clever' coding practices but nine times out of 10, just write it simply and focus on readability. Your team will thank you and you will thank yourself a couple years down the road.
We all used to do this (ii feels right) until we got burned or had to upgrade and rewrite. Now I try to make everything as simple and straightforward. Really helps you scale because yesterdays work doesn' t need to change.
Well written code in dynamic languages is legible. The problem is when you encounter poorly written, illegible code in a dynamic language, the lack of strong types kneecaps your ability to figure out what it is supposed to do.
I loved Ruby until I inherited a project that was poorly written Ruby.
If you are a 10x developer, you should either angle to get 10x the money or dial it down for your own benefit. Don't let some company get free value out of you!
It focuses on hiring the best person, rather than firing individuals who undermine the team. The reality is, there are some 1x developers, and some .5x developers. Even worse though are the -1x developers. So many times I see a corporate culture of firing = bad, so lets just try to find someone who is a "10x", when really all you need is to remove the people who cause more work for the organization.
Its our job as managers to accept that we hired someone who is ineffective, damaging the team and that OUR hiring process failed to catch that. Then to deal with them (training, firing) and iterate on the hiring process to prevent the issue going forward.
I knew two 10x developers at my previous job. One of them was humble and a great mentor and elevated everyone around him. One was a grump who made everyone around him feel stupid.
There are plenty of 10x developers who are socially inept but do very well doing work by themselves, and then there are 10x managers who can deal with those devs well enough so they can work effectively enough in team environments. Unfortunately, good 10x managers are rarer than toxic 10x devs (and a real monster is a toxic 10x manager).
There are also devs whose technical skills have outpaced their social skills temporarily, but they get better later...
Same experience. I learned quite a bit simply by sitting next to an exceptionally good and exceptionally nice developer who was at least a decade older than the rest of the team and enjoyed helping others. He rarely got stressed even in crunch times and that put rest of the team at ease.
The simple idea of this being possible, and picturing the scene in my head, gave me a lot of hope. I'm tired of the atmosphere of fear in the office, and I'm tired of how I participate in it.
I’ll add that toxicity is not unique to 10x. Your last line covers that but many people tend to think 1x people are necessarily more humble by virtue of knowing their output relative to the team. (Assuming everyone believes in the 1x/10x thing)
I’ve known plenty of mediocre devs who would be a 0.5x but thought they should be a 10x and made up the difference in unfounded confidence.
We need to look at the role more broadly, being a developer isn't just churning out code. A lot of young talented guys just follow their passion and hack away abstraction after abstraction instead of trying to see what the product really needs. So you could say they're amazingly productive, or you could say they actually provided very little value.
And a toxic wreck can't be productive by definition; if you demoralise everyone around you reduce productivity! The fact some people can get away with is a bug in hiring.
Most companies don't need a "10x developer", especially if you're building yet another CRUD web app. You need good, hard working people who love the profession and are good working in a team. That's it. It doesn't take Einstein to do this job. Maybe if you're Shopify it makes sense to hire a few of the greatest Rails developers out there (which they did), but otherwise? This isn't rocket science.
I too have met "-1x" developers, but if someone like that persists then either they have political cover or they are very careful about who they show their bad side to. The worst case is if they were hired as a "10x" developer, at which point they can't be fired without their hiring manager admitting they made a mistake.
In some cases, it’s because the cost of letting them go and hiring+training another individual is daunting. Both monetarily and in time. You also don’t know if the new hire will necessarily be better. There’s also other factors like firing someone doesn’t necessarily get you back a headcount immediately. Visa caps also play into this because for certain roles we legitimately could not find enough candidates locally, so letting someone go means you couldn’t find someone till the following year.
I’ve been in this situation where I’ve had to convince my managers that the teams I managed would be better served without certain individuals and I’d rather hire someone new. Even when the entire management chain agreed, it came down to the issues above.
In my experience, the most productive teams are a mix of people with widely differing skills combined with good relationships, good communication, and a lot of mutual respect.
I worked alongside a true 10x (or maybe even 100x) developer on my last job. It was astounding to watch his code changes on the order of 500-4000 lines (mostly front-end JS/TS/HTML/CSS) roll in day after day after day for years -- most of that being new code that implemented planned features and worked. He wasn't really a systems thinker, and he wasn't super big on abstraction, either. But we had 2 other developers who were extremely good at refactoring, abstracting, systems thinking, etc., as well as 4 rank-and-file devs who got their work done. We all filled in where others lacked, and it was an incredibly effective team.
My point is, "10x developers" do not exist in a vacuum, and hiring people strictly for past productivity in a particular environment is fallacious. Instead, try to craft a "10x team" where each person brings something helpful to the table, everyone works hard because they want to, and there is an environment of supportiveness and great communication.
The majority of developers are 0.1x or worse. It's Price's law.
For every passionate and productive developer, there are 10 more who coast and do the bare minimum to not be fired. This has been true in every single organization I've been part of.
And the majority of these have so little presence in places like this, that its easy to forget that they exist at all.
Heck, when I joined my first large-team software development project at work, I was flabbergasted at how many "numb-nuts" there were. This is because the online world of armchair authorities pretended those people didn't even exist, and thus raised the bar so high that it made me believe I wasn't even worthy of owning a keyboard.
I think whether someone is a 1x or 10x developer can depend a lot on what it is that they're working on. If its a codebase they're intimately familiar with, in an environment where they have a fair amount of experience, they can very easily be a 10x'er. Meanwhile, drop the exact same person into the middle of a large project they have little overall grasp of, and they instantly become a 1x'er.
Sure, there is a level of innate ability. And there are plenty of people who will never seem to progress in productivity no matter how much time you give them. But beyond that, how good of a fit the project is for the person can play a huge part in where they fall on the scale.
I don't think the author is a 1x programmer. He has learned the first secret of 10x programming. It's not about being a genius programmer. Its about being an efficiency expert and a problem solver. Soft skills play an outsized role here. I have seen immensely talented developers with hard skills for days manage to deliver nothing over long periods of time.
Learning that rules are guidelines not religious artifacts handed to us via burning bush is a big step. I can't tell you how many programmers I've seen hobble their own productivity by having overly aggressive code reviews, strict style guidelines, or requiring more testing than is necessary.
Being an outstanding software engineer is 99% knowing when to tenaciously stand your ground("storing state that way will not allow us to scale horizontally. It will save us a few hours now but in order to achieve our larger objectives will take 1000x the effort to unwind; we have to find another way") and when exerting control isn't helping("You can't put this simple, but incredibly important, time sensitive piece of software into production until it has been reviewed by our 6 committees, is re-written to use the companies globally enforced, yet questionably valuable style guideline, and has 113% code coverage")
This document provides, especially towards the end, some valuable opinions. The technology-advice is really bland or maybe overfitted to specific use cases.
Agreed. The general advice here is really useful. I am not clear on the benefit of the discussion on programming languages and specific tech though, that section seemed like an out of place admission of a lack of knowledge in an article that contained many useful tips.
I used to get called a 10x developer, I was also called a rockstar and a ninja and a 100x dev and every other compliment that was hip.
Then I hit 30. That type of talk stopped.
Then I hit 40. Now I will not be considered for any entry level, mid level, or senior level software dev job anywhere in the United States, despite being very desperate and willing to relocate for anything. Doesn't matter. Too old. I'm supposed to be doing something else by now.
I'm 40 and I don't suppose anyone has ever called me a 10x developer or a rockstar or a ninja, though I was recently described as having "a superpower to crush tickets."
I have a feeling you have not applied "everywhere" in the United States, but please correct me if I'm wrong. I've never left my home state, and the deluge of recruiter spam on LinkedIn hasn't slowed down yet.
And no I'm not an architect or team lead or business analyst. I'm just a developer. Almost entirely individual contributor roles. But once hired, I learn what is needed and I execute the hell out of it and usually write myself out of a job (or at least make it so boring I am receptive to the next engagement.) This is listed in my résumé as the accomplishments or value I brought to a project. When I interview, I often say "I don't really know enough about that yet, but I'm interested in learning." This is usually met well.
One last thing - my expectations are not great. I'm not ambitious enough to seek out Big Five positions or compensation. But I make really good money for this area and for what I consider reasonably easy jobs. Perhaps you are expecting your career to feel the same way it did twenty years ago? It won't. That's OK. Make peace with it. Find a way to use and improve your skills in a way that brings value to a company, and they compensate you for it.
> the deluge of recruiter spam on LinkedIn hasn't slowed down yet
Recruiters spamming you is not a correlative metric for companies hiring you.
SV is worse than other locations, but even the midwest company I work for (I'm also over 40) much prefers to hire people straight out of college. They're cheaper, willing to work longer hours, and easily molded into an image the company wants.
EDIT: To provide a small anecdote about recruiters - I regularly get Google and Facebook recruiters hitting me up on LinkedIn, even though I know I would never be hired by them. I don't live in a state where they have an office, have no plans to move, and don't meet some of their publicly announced filters. I'm up front about this to the recruiters, yet I still get spam from them.
I’m 45, and was last in the job market in 2018 and before that in 2016. I’m in Atlanta. The last two times I looked for your standard senior/lead enterprise dev roles it took less than two weeks to get an offer just by using local recruiters.
Edit:
There is a huge difference between random spam from recruiters who throw a big net and working with local boutique recruiters who have relationships with local firms. I ignore the former.
I'm in my 40s in the SF Bay Area and recently landed a new software development job. The process took several months.
My initial interviews were disastrous; it had been many years since my last job search and I didn't know I wasn't prepared for the "leetcode era". Drilling on "leetcode medium" problems with a time limit got me to the point where I was at least in the game that's being played nowadays.
It wasn't pretty, but eventually I got around to progressing and getting an offer instead of getting "nope'd" at the early stages. The job-interview repertoire has definitely changed in the last 15 years though, and it takes some work to get conversant with it.
I'm 40 and a developer for 15 years and didn't make it past Amazon's initial code assessment. One of the problems was a floodfill algorithm, which I've never used before. Couldn't quite figure it out on my own, but found the answer in Google in about 5 minutes, which is what I would do in real life faced with this problem. I don't understand the purpose of asking people to memorize a bunch of algorithms they will probably never use in the job and could research if needed. I don't see it as any reasonable evaluation of my engineering skill.
Those tests aren't really about engineering skill. The interviewer is checking to see how much you want the position, how hard of a worker you are, and how smart you are.
If you really want the position, you will put a lot of effort into researching what the interview will entail.
If you're a hard worker, you will intensively study for the interview.
If you're smart, you'll be able to apply the material you studied to the problem, and you'll probably realize the game you're playing.
None of these things is about 'engineering skill', which is much more difficult to discover, and only really valuable if the person is a smart, hard worker, who sticks around.
*edit: I am not saying that I like this style of interview, and when I interview job candidates, I never engage in this type of 'test'
If Trivial Pursuit: Code Monkey and Engineering Edition is the interview game, that's not a place a sensible person would want to work.
A sensible knowledge and performance evaluation would involve pair coding on limited scope, immediate, real problems, not BS trivia.
Interviewing is a two-way street.. the signals given-off in the interview process should be taken in as a totality by the interviewee as well. If they see bad signs, they should run in the opposite direction rather than get sucked into a bad environment.
Well, I think it depends on what the rewards are for getting the job. If the pay, benefits, and accreditation (resume boost) from holding a position at a given company are sufficiently valuable, it is definitely rational to play the game.
Full disclosure; I have never done an interview like this, or tried to land a job at a major 'tech' company, though I do have a degree in engineering.
I think I might have found a hack - a way to work for $large_tech, not to have to move to the west coast, work remotely and not be required to do leetCode - work in the cloud consulting division of either Microsoft or Amazon. I’ll know by the end of May if it works.
This is one of the reasons I haven't applied to work at Amazon, even though I'm sure I could do the work. The signal they're sending by interviewing this way says "We want people who are willing to put up with bullshit".
I had the same attitude pre-Covid. My local market (Atlanta) has completely tanked. There are still jobs out there, but salaries have imploded and I don’t think they are coming back for a couple of years.
If I didn’t have any other option besides the standard r/cscareerquestions “Learn leetCode and work for a FAANG” , I would.
Yep. When I interviewed at Google the recruiter suggested I study up on algorithms, data structures, sorting, graphs, recursion. They even offered a Candidate Coaching Session where you could do practice interviews. It felt like they were optimizing for people that were willing to put a lot of time into preparation .
But if you're capable and smart, you wouldn't normally waste lots of your time memorising details you could easily look up and use in moments if you ever needed them.
Are those interview processes really optimising for candidates who are willing and able to spend silly amounts of time creating an illusion of being super-keen?
While I will say that flood fill is probably too hard for a screener question, I have used it multiple times at work. Sometimes incorrectly, but knowing it helped me realize it was incorrect.
It is true that I use a hard algorithm maybe 8 times a year. But I need my coworkers to be able to understand them when we do. So that's one part of it.
Another major part is having you go into detail about complexity and tradeoffs. Believe it or not most of my co-workers can derrive these things on the fly, not memorized. Others require a little think.
The third is algorithms boil down to simple interviews where only a few things can go meta wrong. There are other types of question but they have a lot more failure modes and are even harder to train people to give.
If the questions are relevant to the job then I think that's fine. In this case, the code assessment is provided even prior to being able to apply to a specific position. From what I gathered, this assessment applies to everything from a team lead/management position to a front-end developer to a firmware engineer.
I understand that for a big company they need something standardized to process a large number of candidates.
I got cut from an Amazon phone screen by not being able to cough up various Minesweeper algorithms off the top of my head. (Also something I've never used before or since.)
Thankfully, at the same time (this was in 2011), I was also in the process of interviewing for a startup that treated me like a real person with individual skills and experiences of value. That interview process went a lot better, and did result in me getting hired.
(And Amazon recruiters still pester me to this day, despite me having little interest in working for them.)
Yeah, SF is probably the problem here... get out to a cheaper state... come down to florida and sling some code for insurance companies... it will be boring but alcohol exists.
No appreciable percentage of employers outside of SV, and maybe NYC, give a shit about LeetCode or probably even know what it is.
SV is an outlier among outliers in almost every respect, even among other large metro areas with big tech industries like NYC, Chicago, or Austin. To the point where advice should always clarify whether it pertains to SV or non-SV, because it's usually one or the other.
The leetcode grind is very real these days. My advice for people is pick a language you want to get more familiar with but have a decent understanding of already. It will help you learn some of the standard but not always used libraries. For example I’m doing some in Python now and had never used the defaultdict class, even though I’ve been using python for 10+ years.
> I’m 45, and was last in the job market in 2018 and before that in 2016. I’m in Atlanta. The last two times I looked for your standard senior/lead enterprise dev roles it took less than two weeks to get an offer just by using local recruiters.
I think I should have tried the local recruiter approach back when I was in Dallas and getting bupkis for hits. Unfortunately, I bought too heavily into the "lol recruiters r trash" meme and didn't consider the type of recruiter before dismissing them wholesale.
recruiters may suck but they're also free (for you) and have contacts. fortunately or not, most of my gigs came from them... especially when I was hoping to work on short notice
42 here. Triplebyte seemed mostly alright, but I got weird vibes (deception?) when they said I "scored almost the highest ever." I bet they tell everyone that, which would come across as patronizing.
Also, I left the workforce because I don't find working for Darwinian corporations or without equity to be a valuable or fair use of my time or meritocratic compensation.
So now we've hit the real root of the problem. If you expect significantly more money than competitors in your role- than ageism may not be why it's getting harder to find jobs.
It isn't 'ageist' to disagree on the value of prior experience.
The real problem is looking at compensation in isolation and not as a function of productivity.
If someone aged 42 is only as productive as someone aged 22, it's perfectly reasonable to offer them only the same salary for the same job.
Of course, unless the person aged 42 has wasted 20 years of their careers (which, I concede, some have) it is highly unlikely that their productivity is really still the same.
A 42-year-old developer who has 5x the productivity of a 22-year-old developer and much more general business experience as well but only wants 3x the salary is a steal, unless you're only looking at the $$$.
Salaries over time are rarely based upon prior experience or knowledge; they are the function of normal annual salary adjustments combined with 5-20% increases when job hopping. Which is, if you perform well, roughly equivalent a 4% annual compound interest.
As they say, compound interest is king - companies are just not willing to swallow the fact that the compound interest is in this case working against them. And yes, it’s working against employees as well: after all, no amount of technical experience can fight against 20+ years of compounded interest.
EDIT:
A $60k starting salary, compounded annually at 4% for 20 years, will be $131k. At the age of 50, they’re knocking on the door of $200k. 60 brings them to around $290k. Just by doing their job.
If anyone is to blame for the “unnaturally high” salaries of those over 40, it’s the companies themselves, plus a bit of math.
The only way your salary won’t go up on a yearly basis is if you’re constantly on the road to being fired. Cost of living increases (2%), as well as small yearly increases to keep you motivated and content (1-2%), are just a fact of life when working for a company.
The only part that’s tied to your perceived value and leverage are bonuses or new job salaries (and most of the time those are tied to your previous salary). I’m not counting bonuses, and getting over a 20% increase when switching jobs is a startlingly rare event reserved for CEOs and the Guidos of this world.
Also, if you have concrete examples to the opposite, I’d like to hear them. Simply claiming repeatedly that they are merit based does nothing to sway me to your position.
IBM, for example, doesn't do yearly raises- you either have to go out of your way to negotiate (i.e. threaten to leave) or you have to apply to go to the next band. I've also seen this at Cisco, and I've heard that Amazon does this as well.
In fact- at Amazon I've heard the opposite of what you're claiming (I've heard this sort of culture referred to as 'up or out')- after a few years you've exhausted your signing incentives (primarily stock options that vest over those few years) and if you stay in the same role for a long time, your total comp will actually decrease
That's certainly true. A better way to say that would be that "I can find work when I look for it, despite my age!"
Also, even my current employer has historically preferred young hires. But as they've grown as a company, and their clients' needs have expanded, they've found value in experienced developers as well.
On the flipside, my current company as a rule doesn't hire below 3-5 years of experience. Especially if their degree is in something like IT or MIS/BIS I've found a junior dev working 60-65 hours a week is noticeably less productive, even to managers and non-tech executives, than a senior dev working 35. Even the person with 5 years of industry-relevant experience will be less productive (though not as noticeably) than someone with 20. We're not in a spot in the market where we can afford the drop in productivity from the seniors, and leadership hasn't yet decided to make the investment required to hire enough to overcome that (e.g. hiring "extra" seniors so we have enough slack to train cheaper juniors and mids).
Have you actually tried applying, though? Rules are general, locations can be hypothetical or ideal, remote work is a thing.
(To be sure, I get your point. But I think this anecdote might be a little bit your own barriers to that route as well as recruiters just spamming people that match keywords.)
> They're cheaper, willing to work longer hours, and easily molded into an image the company wants.
There's no intrinsic reason why older workers are more expensive than younger workers. If you think your experience warrants a compensation premium, then it's up to you to persuade your prospective employer of that; you can't just unilaterally insist that you deserve more pay. If you demand extra pay because of your age and no one is willing to give you that, then your compensation expectations are just out of line with the market. The employers who won't pay you more money aren't discriminating on the basis of age (illegal and unethical), they're discriminating on the basis of salary expectations (legal and perfectly reasonable).
My whole life? Interesting question... since I was 7, so pretty much yes! (And since before I dropped out of college, I've been doing this professionally, except for one summer early on where I drove a truck around delivering hoagies to businesses!)
And certainly. A lot of projects were small enough where I did everything from set up the hosting environment and domain names, build the database, write the application and maybe even do front-end development. But I don't usually have the confidence to be the final point person on larger projects. I suspect I'm getting there. You can only stand to do things that you know won't turn out well at someone else's direction, only to soon watch them turn out poorly... so many times before you start to believe in yourself a little.
> You can only stand to do things that you know won't turn out well at someone else's direction, only to soon watch them turn out poorly... so many times before you start to believe in yourself a little.
In my experience being under 40 is not a prerequisite for being hired in software. A suggestion: two of the biggest turnoffs that I personally see and would work hard to avoid (not saying you have either of those):
1. Sounding desperate. Do not cast a very wide net at one company -- you can apply to mid level and principal level positions at different companies, but do not blanket all job postings at one company. Choose one that fits you best and apply there.
2. Attitude. People with lots of experience often come in with "let me tell you how you should be doing this instead" approach which in most cases is a fatal wound. Learn what problems the company is solving and help them within their constraints, including using their tools and languages even if they look suboptimal.
Just as an anecdote, a friend (close to 50) working in software changed positions in Feb-March and had offers within 2 weeks. He chose to sit out at the dying unit to collect retention money; retention $ required not searching for jobs before he was officially let go, so he started his search from the "unemployed" state as well. It is certainly possible, good luck!
> Learn what problems the company is solving and help them within their constraints, including using their tools and languages even if they look suboptimal.
within reason and 'on day one', yes, agreed. However, if you're hired in because of your skills/accomplishments, but you don't measure up, and it's because their tools/process/code is demonstrably bad, those are constraints that should be on the table for discussion/improvement. In most cases I've seen, those sorts of changes have a net positive for almost everyone on the project (fewer bugs, faster turnaround, whatever), at the expense of being a negative for a handful of territorial people threatened by change.
Not coming in on day one saying "you have to change everything to my approach!" - agreed. Toiling away in suboptimal situations when you know the poor results are improvable for fear of not wanting to look pushy... unacceptable (over a longer term).
Bad ways to point a problem that will make me think you are a 40 years junior with 20 times of 1 year of experience:
- Your stack is bad.
- You should use X.
- Your process is wrong.
A sure way to sound like an experienced senior developer:
- Your stack has this flaw; we can live with it by doing X but that is at the expense of Y1. A migration to Z will cost Y2, that is much cheaper on the long run.
But you'll probably conclude that Y2 isn't much cheaper on the long run anyway. If it's that case that it is cheaper, and even then people above you do not want the change, then you do have a real problem.
> If it's that case that it is cheaper, and even then people above you do not want the change, then you do have a real problem.
Not necessarily so. This assumes the long run is ever reached. I've seen a lot of developers that do this analysis still hop from tech to tech as the best in "the long run", and if you ever listened to them you would never actually reach that long run benefit.
Regardless, a lot probably depends upon the current state of your company.
Some of the re-platform / train up roles which benefit from lots of experience go to consultants (a great place to have a lot of experience and talk to the C-suite, the big consulting firms have lots of older solutions architects doing $10M+ deals - I've been stuck using those solutions in past!).
You can actually take advantage of your age / experience and hire someone out of college for cheap to do some of the day to day and you deliver the consulting "solution" - can be very lucrative. You may be more likely to get the deal talking to the top as a 40 year old then as a 21 year old.
Confidence and desperation hardly ever align. Confident people who plan don't get desperate. Desperate people don't make good decisions. People who let themselves reach levels of desperation are either extremely unlucky (unlikely, but not someone you want on your team regardless) or chronically make bad decisions. At the worst, they're a person who chronically makes bad decisions and thinks they're unlucky.
Standard: not saying it's fair or endorsing this, explaining how people think and feel about it.
> Confident people who plan don't get desperate. Desperate people don't make good decisions. People who let themselves reach levels of desperation are either extremely unlucky (unlikely, but not someone you want on your team regardless) or chronically make bad decisions. At the worst, they're a person who chronically makes bad decisions and thinks they're unlucky.
Disclaimer: I'm saying this for your own benefit, but your comment comes across as incredibly naive, and I would never endorse you as an interviewer with this attitude.
There are life circumstances which one can literally not plan for, and which can derail even the most well-conceived of plans. Chronic illness, war, natural disasters, etc., all come to mind. Give all the examples you want regarding how one might conceivably prepare for one of those things, but it's pretty clear from your opinion that you've never experienced one of these yourself.
Just realize you can both be right. Everything you say is true, but parent is also. Confidence and the projection of ability to get the job done is important. Also when you are 40+ chances are you are going to be hired as a senior developer who has influence on team culture, this makes confidence and positivity even more important.
Sounds like you're arguing based on the "real world", where as the grandparent is based on people's perceptions of it. That perspective is widespread however, whether fair, accurate or not.
I wouldn't rely on a confidence as a stand-in for skill. Maybe it's cultural, but I don't trust people who are extremely confident during interviews. Interviews are stressful experience, people who come across as super confident[1] are suspicious.
On the other hand I'd hire a humble person based on this single trait alone and wouldn't regret most of the time. Humility is an exceptional marker for a good coworker. The best people I interviewed knew their limits and were eager to point them out.
[1] not overconfident, i.e. claiming to know more than they obviously do
People who know what they're doing will over time become more confident.
People who don't know what they're doing will over time become more desperate as they run out of places to fail at.
You could do a lot of work to figure out the difference between someone who knows what they're doing and someone who doesn't. But it's a lot easier to just notice if they look confident or desperate.
Unfortunately, being confident is actually super easy if you're willing to practice it. Much easier than actually being good at anything.
Also unfortunately, being confident is really hard if you don't know how to practice it. And the skill is orthogonal to most other skills. So if you're good at something, it might actually be harder to control how confident you appear to others.
Unfortunately in all parts of life confidence sells. If he gets an interview and gives off the signal that he will take anything, odds are they will pass figuring there is a reason he will do so. Same concept unfortunately goes for looks a lot of the time. If you walk into an interview not well put together its going to work against you. This can be mitigated by youth but when you get older you no longer have this luxury. I'm early 40's and I make sure that a couple months before I start thinking about changing jobs I up my workouts, change my diet etc to appear in shape and more energetic. It has zero reflection of my true abilities but people are judged by their looks and unfortunately older people are double so.
Would you want to date someone who seemed desperate to get into a relationship? Who seemed like they were having trouble getting a relationship at all, let alone a good healthy one? Same principle.
The same reason that "what's your biggest weakness" is such a stereotypical interview question. It's all about stories. If you can prove you're the best with math or with certifications or whatever, that is only a protection for yourself. But if you have a good story that is a protection for whoever you tell the story to.
What's your biggest weakness is all about your ability to tell a good story about a failure that you're responsible for. Because if you have a good story then the person responsible for you can retell the story to the people that they answer to.
Yeah, Joe messed up big time and then left the company and I was responsible for him, but listen to this great story that he told me about why everything was going to work. Clearly this failure was from external forces that shouldn't be held against me. Anyone else would have failed; it was inevitable.
Desperation isn't a good story for anyone. Yeah, I left Joe in charge. And he told me that he knew what he was doing. But he also seemed really desperate (and everyone could tell), like he would say whatever he had to in order to get the job. Yeah, this is clearly all my fault and I should probably be fired too.
Well if this were sports and people had fixed time commitment contracts that makes sense. But for at-will employment, they're likely to move on once they're not desperate. You want a good fit, not a bargain.
Becuase top talent usually don't get desperate. It's a bad way to judge someone, of course, but there aren't many good ways, and when hiring, you want to play it safe: not hiring a good candidate is way better than hiring someone who turns out to be bad. So, if you notice something that looks like it might have been a red flag, you take notice.
"not hiring a good candidate is way better than hiring someone who turns out to be bad."
is it though? CA is at-will employment, so there's literally nothing stopping a company from firing someone that isn't working out (besides timidity on the part of the person who would have to do the firing).
"when hiring, you want to play it safe"
personally, i'd rather tell some people it's not working out than miss out on incredible talent because i'm too scared to fire someone.
i prefer to lean into strengths, not try to shore up weaknesses.
"top talent usually don't get desperate"
there are many reasons why people look for jobs, on their own timing, and with their own reasons. reading 'desperation' into someone's application is projecting your own fears and experiences onto theirs without actually taking the time to learn more. it's lazy.
> is it though? CA is at-will employment, so there's literally nothing stopping a company from firing someone that isn't working out (besides timidity on the part of the person who would have to do the firing).
Last I checked, I was 9700 kilometers away from California. Not everybody on HN is from Silicon Valley.
> personally, i'd rather tell some people it's not working out than miss out on incredible talent because i'm too scared to fire someone.
Then you've never seen one bad hire destroy whole teams.
> reading 'desperation' into someone's application is projecting your own fears and experiences onto theirs without actually taking the time to learn more.
This thesis has no null hypothesis. The same arguments could be applied to about anyone who's perceving any emotions from other people, in any context, aside from listening to a person narrate his emotions out loud. See, none of us have any emptathy or eye for emotion, we're all just projecting something of our own. And if you, or anyone, has any counter-argument against this clearly absurd statement, the same counter-argument could equally rebute yours as well.
> Last I checked, I was 9700 kilometers away from California. Not everybody on HN is from Silicon Valley.
So... you have strong labor where you live? Where do you live? Employment is not at will? Everyone gets a contract with a specified time? Saying you live far away doesn't address whether employment is at-will where you live.
> Then you've never seen one bad hire destroy whole teams.
Nope, never have. Ever. My anecdotes are as good as yours.
> This thesis has no null hypothesis...
Lots of word salad there, let me break it down for you: without speaking to someone to learn more, your interpretation of "desperation" based on their resume or what jobs they apply for alone is a projection of your own insecurities. Maybe they like several of the jobs at your company and could do them equally well. Just because you would feel "desperate" if you did that doesn't mean everyone does. All your gymnastics about hypothesis and arguments don't actually address any of the real issues that the post is about. Pretty self-congratulatory about knowing words.
Just in case anyone reads this and gets very worried about getting older and being destitute, its certainly not always the case.
I am 48 years old and having a blast. I am team lead working in the companies CTO office. I play around with build systems, making everything cloud native (kubernetes) and I get to work on a good amount of upstream open source projects. My company does not see my age at all, they just see me keeping busy and constantly pushing to learn new tech. I would say overall in our team, the under 25's are the minority.
I think you're attitude helps. I still feel like I am a kid in my head and I get massively excited about tech , even more as time passes. There is always something new to learn.
I can implement streaming architectures using the latest technologies that can handle throughputs of TB per hour. I can handle the architecture, security, infrastructure as code, and monitoring, as well as the development. I can also help with price vs feature analysis. I have demonstrable experience in doing so, with happy references. I can do it much faster and more successfully than a recent college grad.
Shouldn't minimize the reality of getting old.
Edit: Just in case this sounds snarky, it is a bit. But that first paragraph sells well. I am sure if I was making crud apps in Node I would be a much harder sell. A younger, recent grad can definitely out price me and do a wonderful job.
Well, I didn't say I do security alone. The types of companies I work with other have an entire security group. But I can absolutely begin the architecture with proper security principles in mind and I can go through the review process with both peers and groups. I certainly know where to start with security and the security issues inherent with eventing and streaming. Which I guess is the point. I also don't often engineer the entire application from soup to nuts but I guess I technically could.
If you have a role now, start working with the architects to gain experience. Become friends with all of the architects. Learn from them. Then ask your organization to move you to an architectural role. Maybe without any sort of pay increase. The point is to get the verifiable experience on your resume. Then you can move.
I get to fix other people shit code because our tech lead has an attitude like yours and has made poor tech decisions in the past in order to learn new things. He is too busy learning things and building new parts to the system to to write any tests or document anything, or even to explain things properly.
If you chose the word "desperate" deliberately, would you mind telling us/me why someone with two-to-three decades of experience becomes "desperate" for a job?
What did you work on during those years? Did you keep up with the industry?
I am asking out of interest for both you and me. For you, I want to help you regain confidence that is rightfully yours, because someone with your experience should not need to feel desperate. For me, I want to know if there are objectively speaking potential career missteps one should avoid.
A lot of the coders over 40 that I know who are experiencing difficulty finding work are coders who spent years working at the same place and chose specialization over staying current. They chose to become the J2EE guy with 10 years experience at a fortune 500 or the off the shelf ecommerce specialist. Being overly loyal to these companies and seeking job security left them with little career security at companies who are quickly being convinced to hire young former Amazon and Google employees to replace them.
Based on their experiences I think the best advice is to stay current in your skills, find ways to apply those skills at work so you can get those lines on your resume, and choose to be a generalist rather than specializing. Don’t be loyal to your language or framework, demand for skills in software is more a function of whats fashionable than anything else. Look at where Perl is, many Perl coders were loyal to Perl instead of learning Python.
Most importantly, take a look at the ages of your coworkers. Is it really smart to be loyal to a company where there’s few people over 40 working your job? My Dad stayed at a company for 10 years and only got a raise once. Be smart, at some places you’re just a line item.
Some companies are definitely friendlier to older and longer-tenured employees than others. I've been at my current employer for quite a while and even I was a bit surprised at the number of 20 year anniversaries shown at a recent meeting.
Many companies people apply to work at haven't even been around 20 years, let alone have staff with 20 years at the company.
There's a whole subset of folks looking at 'tech' as 'startup', and the goal of those companies is often to get acquired, so, the company won't necessarily be around in 8 years, let alone 20.
I've resigned myself to the notion that I'll never get a '20 year anniversary' at a company at this stage of my life. I don't mind, but it was one of those things when you're younger that does seem achievable. Most of the companies I've worked at in the past 25+ years aren't even in business any longer, except for 1, which was already 15+ years old when I started, and that was 15 years ago - had I stayed, that might have been the one chance to hit a '20 year' mark someplace (and I have one colleague who started with me and stayed there, so he might make it).
This is really good advice. Outside of a few specific areas, most companies don't need someone who's "the best" at skill X. The need someone who's decent at skills X, Y, Z.
Line-of-business apps. VB.NET maybe? Or Java/J2EE type stuff. Probably jobs involving mainframes as core legacy systems? Things where "design" was more a function of where your WYSIWYG editor placed controls than conscious decisions.
> Did you keep up with the industry?
Enough to read HN, but not enough to keep learning new technologies and not languish at the same company for a decade writing the applications mentioned above.
"I'm over 40 and now nobody wants to hire me because they're age-ist bigots!!1" is a common refrain that very rarely holds up under any form of scrutiny.
And let's not ignore the fact that if you removed speculative comments with no relevant information from HN we'd lose about 2/3 of the userbase.
Not OP, but I have an answer. Had to take some time off to deal with the fallout from a nasty divorce. Afterwards, was financially "desperate" due to alimony (which assumes that you never take time off and can always get a new job that pays the same as your prior one).
Turns out that it really is hard to get a job when you don't already have one.
I have noticed that I was the 10x developer - when I was working on a system that I designed an built. Now I am fixing someone else code and he gets 10 times more done than me. Is that because he is smarter than me and get more done, or because he is worse than me and writes code that is obscure for someone else to understand quickly? Obviously its a subjective question, but volume of features completed isn't the only measure. Technical debt can be fairly subtle.
The idea of a "10x" developer isn't suppose to be taken so literally.
My personal definition of it is just a developer that doesn't get hung up on issues. Majority of developers I've worked with can get stuck on the same problem for a week that a 10xer can solve in a couple of hours.
The difference is the 10xer understands the system and tools enough that they don't get lost in the weeds. And the other developers do get lost in the weeds. Which of course means a 10xer in one environment won't be it in another environment if they are dropped into it without adequate time for training.
IMHO you have to measure productivity with debugging time included. If you’re fixing the bugs in someone else’s code, the only way to measure productivity is to measure the both of you as a whole.
For me the real 10x skill is knowing when to write code and when not to. Too many programmers code their way out of a problem, instead of reconsidering the problem in a way that they can repurpose something that already exists.
Yeah, I hear you. I'm 49 and it took 2 years before I landed another dev job. I gave up looking after a year and trained for an HVAC career only to find out I was too old to start in that field; I suppose my previous salaries scared employers off as well.
I must have had 50 interviews in that time. Some I knew I failed and others I thought I nailed. There's a lot of luck in interviews, good and bad, but I think it usually comes down to personal biases and 'fit.' Sometimes I'm not technical enough, like when I interviewed at Facebook and Amazon. In that case Leetcoding would help, but you still have the whole 'fit' issue to deal with.
In April of 2019 I landed a dev job. I only got it because a friend referred me and the interviewer had worked at the same company as me and my friend Luck strikes again...
I'm 38. I know 40 seems to be the cut off, but in the Boston area no problems finding a job.
I will say that I interview devs at my current position. I have noticed that a lot of the older people who come in and have years and years of experience at one place don't seem to have the breadth of knowledge we are looking for.
For example, recently before the lockdown I interviewed a guy with over 20 years experience, most mainly at one company for a .net role. He didn't know any of the latest features of the language, including Linq and async/await, never used .net core, no NoSQL experience at all.
We didn't hire him and it's not because of his age. We have several "older" new hires in my engineering department, but it seems like a lot of the "older" people have lots of experience, but at the same company where they fall into complacency and don't keep up with what is happening in the industry.
Not saying this is the case here, but when interviewing this guy I mentioned, this site popped into my head because this is not the first time I've heard people complain about age discrimination in tech here. I have to say from my personal experience, I haven't seen it. Not once has anyone on our interview team said anything about an interviewees age, only the amount of experience someone has. And even that is treated as a positive as we just assume they know their stuff if they've been around for 20+ years.
I have also interviewed a handful of people that had 20, 30 years of experience building software. In some cases, they had resumes pages long dating back into the late 80s. One tip I would stress to anyone who has been doing software engineering that long? Don't list all of the history you've ever had. Go back maybe 10 years. If you're worried someone might miss something you built from 15 years ago, just put "more job experience history available upon request" or something like that. The simple truth is having built something in Delphi in the 90s just isn't going to 'help' you working with today's frameworks, even though the underlying core software engineering skills will almost certainly be relevant regardless of language, toolset, or framework du jour.
The best developers only have 10 years experience.
10 years is enough to understand software, process, and the rest at a deep level. You may have expertise in a particular area. You know pretty much all the things that are available to know.
After 10 years, the previous experience becomes irrelevant and "drops off". The languages you learned? Gone. The APIs and weird hardware limitations? Irrelevant. Nothing beyond 10 years matters.
One career mode is to shift to management. Or move to a technical leadership role where durable interpersonal relationships matter. The other career mode is to keep learning. Learn the new stack, the new language, the new whatever. Keep learning.
I think that some developers hit trouble around 40 because they spent their first 10 years learning, then realized that they knew everything and coasted for 5-7 more, and then show up at 40 years old completely out of touch. Imagine a hiring manager considering someone with only 2 years of relevant experience (and a demonstrated unwillingness to learn), who is nevertheless convinced that he is super-senior and demanding compensation to match. That's the reality.
I think that much of what we call ageism is just the natural consequences of a fixed mindset. Make every 10 years shine. "What have you done for me lately?"
I agree with your gist of "keep learning", but some of what you say about obsolescence of knowledge seems overstated to me.
> The languages you learned? Gone.
I'm not sure if I'll ever get to write Modula-2 again. But every few years, knowing some PostScript can come in handy. FORTH has a tendency to pop up on every resource constrained platform for a while. Tcl has preserved some niches.
And C++ is both old and new technology. Some details have stuck around for 35 years, but if you don't reinvent your style every 10 years or so, you risk becoming obsolete.
> The APIs and weird hardware limitations? Irrelevant.
Hardware limitations tend to come in cycles. Just when resource constraints on macOS seemed irrelevant, along came iOS with its murderous daemons baying for the blood of resource hungry processes. Just when resource constraints in iOS seemed irrelevant, along came watches.
And a Commodore PET with its 7167 bytes of available RAM and fairly accessible hardware ports has some similarity with an Arduino Uno.
So while I think it's unwise to bank on some knowledge never ceasing to be useful, or that no new technology is ever worth learning, knowing old stuff in itself is not a drawback.
> After 10 years, the previous experience becomes irrelevant and "drops off". The languages you learned? Gone. The APIs and weird hardware limitations? Irrelevant. Nothing beyond 10 years matters.
The experience you're really paying for with an older developer goes way beyond that. It's having a "deep" memory of a number of projects that have failed. It's having a true understanding of the value of quality and reliability. And being able to set the right level for each situation. It's about taking the time to get the requirements right, rather than just implementing what it sounds like the customer wants, only to find out months in that they don't even know. It's about showing up to the job every day. It's about knowing better than to just jump to the next job after a few months.
If you want to experience youth, ask a young team how they're planning to deal with disasters, and watch the blank looks.
Even for the tech aspects, it's very useful to have experienced the history to know why things are the way they are now.
One of the reasons I'm so valuable now is because of what I was doing 25 years ago. As you're implicitly noting, it's hard to sell that, but that doesn't mean it's not so.
Those are currently the top 10 most popular languages according the TIOBE Index. The idea that everything turns over immediately is maybe true in the valley, but it isn't close to being true industrywide.
This is true, but for a pure dev role (writing code, closing tickets, no technical leadership) I maintain that a C expert with 10 (recent) years' experience is functionally indistinguishable for a C expert with 35 years.
Is that because the previous 25 years experience from the one dev is now obsolete or because you essentially know all it is you need to know to be a great dev after 10 years? The first comment stated the former, but this one seems to be implying that latter.
That probably depends on the industry. At my last job (embedded software for a defense contractor), I was actually the youngest at 28.
The guy to the right of me was in his mid 60's, the guy behind me was 50, and my boss was 52. I think the only other engineer not over 50 was this one guy who was in his late 30's.
It seems like in the defense industry, it's almost the opposite.
This has very much been my experience. I used to be the young guy. Now I'm the middle aged guy. I work with all kinds of developers older than I am all across the embedded software industry.The oldest guy on our team is in his 60s. It helps that tried and true technology which still underpins everything else (C, POSIX, sockets, serial comms) doesn't drastically change with every new hype and trend. Sure, it changes and will change but in units of decades. The next airplanes aren't going all Rust any time soon. And even cutting edge companies like Tesla/SPACEX need old school C programmers. And when/if it goes all Rust or something else, I don't think us old guys are going to have too much trouble switching over, and the ones who do can spend all their time maintaining legacy systems. In other words, I don't see how I (in my early forties) could outlive my usefulness.
I think there is ageism in the industry, but you must have other problems to get that result. Either you're not applying to enough places, or your resume needs work, or something else. Because there are a lot of successful 40, 50, even 60 year old developers.
I can't say much personally, other than at 36 my career is still on an upward trajectory. I've worked 50-60 hours a week my whole career though, not for the company usually, but putting in time on side projects, learning new skills. I think part of the problem is once you have a family, priorities change and you don't have that kind of time to stay on top of the game anymore. That doesn't mean you can't compete, you have other advantages on the youngsters - you just need to play to your advantages.
SV start-ups need bright shiny twenty-somethings for their "About us" pages and their IG lifestyle feed, with a few wise old thirty-somethings to ride herd on them.
It leaves room for the forty-something and fifty-something VCs to do what they enjoy, which is pretending to be the team coach.
Put in some wrinkly old guys - or worse, some old women - and there goes your brand identity.
I am 48 and having a blast in my career now, I am getting my hands on all sorts of interesting things to learn.
The only people who I have seen struggle with this are those who just go stale. I have friend who is a C++ programmer, and for 30 years all he has worked on is some logic controller software used in trains and energy systems. He is getting close to retirement, but if things go tits up due to COVIDs impact, he will very likely be unemployable. Me on the other hand. I get daily connect requests and job interests put my way on linked in.
I think its more of a SV thing than a U.S. thing. There are a ton of older coders in my industry and having experience, especially if you have domain knowledge in addition to technical skills, is huge. Most companies in my field would gleefully hire a 50 year old coder with domain knowledge over a coding rock star straight out of school who doesn't know the business.
I'd say in the Netherlands it looks almost the same I am 33 and usually work with people in their 40's. Seems like all kids are moving to US and take jobs of older people :)
I think a big factor is health insurance in the USA. If you are in your 40's you probably have a partner and kids. Your company will have to cover all of this, and if the kids get a condition things can be expensive. So, I think that they consciously focus on younger people to drive the costs down.
The only problem I could imagine with being 40 is a certain attitude; if you come to interviews too confident and give the impression you're there to teach everyone and show them what's what, it could be off putting; even if you ARE more experienced and are hired as a senior, the people hiring you want to know you're gonna be a good sport and not MR know it all. Or it could be something else completely. But I would definitely explore attitude some more.
I got a remote coding job at an outfit advertising for "young developers". I just severely abbreviated my resume and didn't mention my age until well after I was hired. (The benefits paperwork went through a third party.) It's now years later and they still haven't seen my grey beard, which doesn't matter any more.
And I really like working remotely. If I lose this job for whatever reason that's Plan A, not the backup.
I know plenty of devs who are 40+ and still writing code and getting paid well to do it. In fact I worked with a consultant who was over 60 not too long ago.
I am almost certain there is something else going on here other than your age. In fact, I've never once been asked my age in an interview, and I'm a couple of years into my second career doing this after I retired from my first.
Even if the interviewers were concerned about your age, you'd never be asked how old you were in an interview. That's grounds for a discriminatory law suit basically anywhere in the world.
>That's grounds for a discriminatory law suit basically anywhere in the world.
Not true, in German speaking countries having your photo, birthday and work/graduation dates in your resume is basically mandatory, especially when applying at big established companies.
Omitting them could have your resume disqualified as HR might think you're trying to hide something or that you haven't bothered to do it right.
I hear this from time to time. I'm not sure I buy it.
1.) Most people can do math. Unless you're also going to be evasive more or less throughout your resume about how long you were in roles and the like, people are going to figure out your rough age/general seniority pretty easily. And at some point it looks evasive. Maybe you're trying to hide some big gap that exists for some reason.
2.) But let's say you do scrub your resume and no one calls you on it. You're presumably going to have an in-person interview at some point and they'll, again, figure out your approximate age pretty quickly unless maybe you're exceptionally young looking.
3.) All this assumes that no one actually knows you when, in my personal experience, every job I've taken since grad school was through someone I knew.
I rarely apply for a job cold. I've nearly always had some point of networking somewhere.
Even for the job I have now, for which I did just send in a resumé and an application cold, I have some very specific key words on my resumé that the hiring manager recognized and then started asking if I knew person x and person y and so on and we discovered that we have a bunch of prior colleagues in common, which also made me extremely useful to the organization in ways they don't advertise (I already knew this going into the interview, as I did my research).
Finding a job is very much about market segment, branding, and networking. If you're "just another web dev" and have no other meaningful skills and no friends, then maybe finding work after 40 is hard -- I wouldn't really know. If you're a C++ guru with an MS, an embedded dev, a specwar comms tech, etc, you get really valuable to some people because you've got such a broad set of experiences, and they don't give a rat's ass how old you are as long as you can still hobble in to work some days.
And sometimes they'll hire you for your network as well, which isn't all bad either.
1) I'm assuming if you're old enough to want to keep years off your education, then you're probably old enough that you're not putting work history from your early/mid 20's on your resume. Maybe you're 40 and only need to put your last 10 years to show relevant work history. This probably varies a lot person to person, but for me it works very well.
2) Getting an interview is all a resume is good for in the first place. Now they've invested their time in you and you have a chance to sell yourself.
3) Same here, but even people who "know" me professionally don't necessarily know my age. I certainly don't know all of their ages! Plus if they know you, they already have an incentive to care less about your age.
But my point was that there are market segments where age literally doesn't matter one bit.
I'm retired from my first career and writing code every day for a second career, well over 40. I've interviewed for five jobs in that time frame and been offered every single one -- and I don't interview for management roles because I hate managing (it's what I did for 20+ years in the Navy).
In my experience it's not about age. There are jobs, one just has to find what fits them.
Our biggest rockstar on the team is 60. He's incredible. I have worked with workhorses before. Careful, eager to learn, and prodigious.
This guy blows those "workhorses" out of the water. He's a Clydesdale. He literally makes everyone else on the team (including me) look bad in comparison. He's THAT good.
He acknowledges that due to his age, he has to work harder to prove himself. On our current team, he no longer has anything to prove, yet puts in rock star performances day after day after day. I could go on but you get the point. Don't give up!
Being in my 40s, too. Also started my career out as a really solid dev working for the top companies in the business in the 90s (probably one of the best).
I found my dream job again, after getting stuck somewhere after the former company I worked for was acquired by big NY finance.
I was fairly lucky, because I was still pretty relevant, on my game, studied all that college alg stuff again, and I even was flown out to FAANG companies for interviews, etc.,
But I still interviewed at 40 places to get a single offer.
Tech also changes so much, that someone with 10 years of the wrong experience (legacy tech), is less important than 2 years of the vNext tech-stack.
You need to really a) lock in what people are doing for technical coding tests these days, sure it's gate-keeping, but it is what it is b) make sure you've gotten some coaching on how to answer a lot of the soft-skill questions (you know, the fluffy stuff that devs typically think don't matter, but that are used to build an impression of you speaking....lots of websites out there.). And you'll need to change your mindset a bit, likely, into thinking like your younger-self, and not like hey, I'm 20+ years experience, etc. Pretend like you have 5 years experience, and go for it.
I’m in my 40s, I have had dozens of interviews. My non rejection rate from application (via a local recruiter) -> phone screen -> in person interview is close to zero. Not because I am a special snowflake, but I’ve built up a network of coworkers, former managers, and local trusted recruiters.
I have never in my life had anything approaching a hard algorithm coding interview and I didn’t know such a thing existed until three years ago after being on HN and reading r/cscareerquestions.
I’m a standard enterprise dev living in Atlanta. Pre-Covid, the job market has usually been good for me since 2000 when I got my second job after leaving my first job I got based on an internship.
There were even jobs/contracts available between 2008-2011
I think I am above average soft skill interviewer FWIW.
I'm a SWE hiring manager. I love to hire older, experienced devs. I want somebody who can be self-directed and can effectively talk to stakeholders to come up with a good solution. My experience has been that (some!) older developers are more able to do this.
That said, if you're an older dev that hasn't kept up with the times, I'm prob not going to hire you.
Uh then there is 0 difference between an older dev and younger dev (by your own definition other than age). An older dev that 'knows all the new tech' may not have the concentration you need. You can not tell me as a hiring manager if you see someone changing jobs every other year you think it odd? I know I do when I see resumes like that. If they have the right skills I ask them to explain it.
You are just justifying being ageist. You mental gymnastics to do so are in your second to last line.
Exp in older stacks, that are 'obsolete' in your eyes, has helped me so many times with newer stacks. They usually make the same mistakes/patterns and have the same bits connecting it together at the OS level. A more experienced dev from another stack may say 'hey if this stack had XYZ from this other stack this would be so much easier' They then will get that thing done.
If you are skipping people because they do not know your particular stack you are missing out on a lot of people. The fresh young grad is not going to know any stack and will have no exp to draw upon when it goes sideways. That is why you pair them with someone who does have that exp to draw upon. Sometimes you want that crusty old ways too. Linux is a hodge podge of tech smashed together drawing from well over 40 years of tech stacks. Each with its own quirks.
I can't agree. I turn 50 this year and it's easier than ever to get a new gig. If anything I've noticed a bias in my favor where I would be viewed as a stabilizing force on the team.
This. I'm in my late 30's and have routinely beat out younger people with stronger tech skills simply because I have domain knowledge and experience in the industry, in a addition to technical skills.
I'm over 50 and have a great job with lots of interesting work, coding and engineering, at a large company. I worry what would happen should I get laid off, though.
I can tell you that age will not matter all that much if you look at rather rough, atypical positions like universities, city governments, and small/medium businesses (all unfortunately mostly not hiring right now). They could care less that you're in your 40s, but they'll try to hire you like you're in a different industry and do things like validating that you can use Excel, have people who don't know the position interview you, make you retype your resume 3 times to fill out the application form, and have obnoxious policies with respect to vacation time or retirement vesting.
Yes, positions aren't competitive, etc., but they mostly get really rough applicants and are happy that anybody who knows what they're doing applies, and are probably better than no work.
This is kind of what I did, and recommend. Salaries are humble, but it's nice to have an employer that's grateful rather than dealing with contempt (of the sort we're seeing here).
And you can end up with an amazing amount of freedom on technical choices, etc.
Do you think the hip compliments to you were warranted?
Or are you saying that it's just something people reserve to tell young people. Can't quite tell.
I have a hard time believing this. Age is never really a factor for us when hiring. What does come into consideration is whether your resume is filled with "architect" and "CTO" and "tech lead" but you're applying for a mid-level role or if you apply for a more senior role and you can't solve simple technical questions.
We have several engineers on our team that are 40+ that are either senior or principal developers. Age never really came up in the discussion. Just their experience and how they did in the interview when talking about that experience and when encountering new problems.
>Age is never really a factor for us when hiring. What does come into consideration is whether your resume is filled with "architect" and "CTO" and "tech lead" but you're applying for a mid-level role or if you apply for a more senior role and you can't solve simple technical questions.
You are saying that age isn't a factor while also saying that a person can be too experienced for a role. Age and experience are highly correlated. So while you aren't specifically saying it, you are certainly implying that someone can be too old for a specific role.
As someone in his 50s I agree that job search gets more difficult once you get older. But there are plenty of companies that have a lot of older developers once you start looking outside Silicon Valley startups. Maybe the jobs aren’t as glamorous but they are there. One good way is to work through a contracting agency that places you. There is way less age discrimination that way and a lot of contractors get converted to full time after a while. Happened to me and I know quite a few others.
The only painful thing to get over is the realization that you aren’t viewed anymore as the hotshot you thought you were in your twenties.
Have you looked into Consulting? I'm mid 30s and I see consultants way older bringing in cash by jumping in on projects that are using a slightly older stack (not all the time older) and crushing it. Seriously there is work out there for consultants and they can do awesome stuff. I've even seen consultants at startups. Good luck!
I am almost 40, and I fully expect this to be my last software development job. Likewise, I've never had a negative performance review and am usually the top task-killer and bug-destroyer; but when recruiters call and find out I'm married with kids they can't seem to hang up fast enough.
I often wonder if it’s because they know you’ll have a healthy work/life balance and say no to ridiculous “we’re all in this together” pressures to work well past what’s in your contract, and hence aren’t as attractive for them to promise to employers looking for Ferrari’s on a ford budget
> when recruiters call and find out I'm married with kids they can't seem to hang up fast enough.
I don't really understand why this would be the case. From a purely practical standpoint, people loaded up with a family are more likely to stay and perform in a job for income stability.
I guess if a company is looking for people to burn through like firewood this might not be the case, but I think those are the places you want to avoid anyway!
Dam dude, what sort of people are you working with or interviewing for, that they see having a wife or family as a negative? That's just crazy. Is this valley based start ups or something of that ilk?
I don't understand why marriage or dependants would come up. If anything these two life changes forced me to take my career and profession a lot more seriously.
It's not legal for prospective employers to ask you these kinds of questions. If you're talking about your wife and kids during the interview process, you're doing it wrong.
My last round of interviews was at age 46. Went from being (voluntarily) unemployed to a FAANG job. I had to do the same stuff the 20-somethings do: practiced hackerrank, answered stupid whiteboard dynamic programming questions that have nothing to do with the job, etc. But at no time did I talk about my personal life with anyone involved in hiring.
Do people really ask about hobbies? In actual professional job interviews?
The other questions only lead to answers that involve your personal life if you choose to talk about your personal life. Job interviews are professional negotiation, not chats with friends. Where do you see yourself professionally in 5 years? Why would you mention your family?
Asking if you're willing to put in lots of overtime should be a red flag for a job at any age, and answering it shouldn't involve mentioning your kids.
Can you work in the US? Maybe there's issues where the answer varies based on marital status...
Hobbies? Of course, particularly in entertainment software. It shows if you have a unique perspective that could be advantageous to the creative process.
I would mention my family for any professional prediction because it is a guiding factor; in five years, I see myself continuing to be a product lead and hopefully working with my daughters on an independent project of their own.
I work in entertainment software, in British Columbia; overtime is normal, working 40h a week or less is not. The BC NDP stripped tech workers of their basic employment rights, around two decades ago; among those rights removed was any right to overtime compensation.
I can't work in the USA _easily_ and I would _prefer_ not to; I have no interest in raising my kids there. But I've worked from home for five years and so I don't see why I should have to relocate. :P
Asking a candidate's hobbies is a recipe for pure unconscious bias. It immediately hooks into your preconceptions about the type of person you'd expect a snowboarder/surfer/sewing enthusiast/furry/birdwatcher/lego collector/"I don't really have any hobbies besides programming"/whatever to be. There are better ways to get a glimpse at culture fit and creativity.
When I was younger and working in game development, I probably got asked about hobbies. Nowadays I'm generally pretty good at directing conversations like that politely back on track.
As for mentioning something you want to do with your kids in 5 years? In a job interview? I don't understand it but I suppose some people want to talk about their home lives during job interviews.
And thanks for reminding me one of the reasons I left game development. I don't miss having just work/work balance. :-)
Part of it is that I don't live in California, and the tech culture where I am (Vancouver, BC) and the industry I prefer (Entertainment) is somewhat different.
Maybe you just aren't as good as you think? Maybe you need to work on interview skills? 4 of the 4 companies I've worked for have had more people over 40 than under 40 who were devs. Blaming the industry for discriminating on age is very easily disproven by looking at all the people over 40 who are devs...
At your age, you should have at least dozens of former coworkers who enjoyed working with you and would unreservedly recommend you to hire where they are now.
I'm 50+ and that is how I easily get jobs.
Now, (and I'm not saying this applies to you) if no one you worked with before wants to work with you again, that is a real bad sign.
Yes to being trainable, but good luck getting training. I jumped straight into mid-level roles. No one would take me seriously for a junior role, so I used failed interviews to learn how to sound more experienced than I was. Then I got in over my head and failed my way up for a couple years. That is also my anecdotal evidence for software engineering interviews being crap. If someone w/ less than idea experience makes you think they have enough maturity to do the job well, maybe your interview kind of stinks.
Embedded development is safe from the young turks in the US. Nobody is being taught how to competently develop in C and work with hardware. There is no apparent ageism where I work because older devs are in demand for skills that aren't available in a younger cohort.
This. Embedded isn't in love with the latest web framework. Skills live for decades, not for minutes.
Now, even in embedded, not every employer sees the value in 30 years of experience. Those that do, though, understand that such a person is more valuable than someone with 5 years, and will pay accordingly.
I worked in embedded (mobile phone OS) about 8 years ago (UK). The pay was appalling for such a high-skilled job. I could have doubled my salary if I changed to flinging out JS for some website.
The pay is appalling in the UK. The "problem" with businesses that build hardware is that there is a lot of additional work that needs to be done to make something physical. The extra headcount means that developers can't demand prima donna compensation. If the base compensation for pure software devs is already low in a country, then it will not be able to sustain a domestic electronics industry.
I started my career at Motorola, I saw so many senior(read: old) engineers working efficiently and staying updated. They're eager to teach newcomers. It gradually stopped when the outsource era came.
I notice over the years a few star players in their 50s and even 60s are either unmarried, or married without kids.
I have kids and I'm in my 40s, I plan to work until 65 for coding. If nobody hires me, I will try to get something done(SaaS?) or consultation from home. I probably don't need that income to survive(by then the kids will be out so the finance burden will be more tolerable). Working is the meaning of life for me, it has nothing to do with my age or if anyone hires me. I will keep studying and working no matter what.
I was 35 when I had been working a decade on a large enterprise product built on legacy tech: a legacy php framework, a legacy js framework, and desktop apps built with delphi. My job prospects were not great. Recruiters did not reach out to me.
Then I managed to get a new project and used it to learn new technologies: modern java, scala, modern js, hadoop, spark, and so on. In the same period I also gave a bunch of tech talks at local meetups. By 38 I had a resume good enough that I basically picked my employer and job of choice, applied and was hired immediately. Recruiters contact me all the time.
I don’t want to say your resume is your problem having not seen it, but for me it definitely was.
Your backup plan is to differentiate from younger developer.
I have defined my advantage should be experience, wisdom and maturity. I try to deliver something to my managers that they just can't get from a developer that is very bright but has just couple of years of experience. I try to spend more and more of my time learning and deliver with less time expenditure.
Also, don't get discouraged when you don't get a job somewhere because you are an older guy. You should be thankful that you did not get the job, probably it would be a dead end anyway.
You don't need every place to accept your age. You just need one -- one where you will feel at home and be happy offering your services.
That scares the hell out of me. I started working in IT at 22 and now I'm 30.
I'm SRE and I think of myself as a useless lamer compared to the real 10x guys around. It gets heavier every year.
I got bagdes CCNP/OSCP/RHCE/CKA/AWS DevOps Pro/etc only to confirm that I know at least something. (I don't tell anyone about them so I don't become known as a paper tiger.) On my way to CCIE.
I study things and write code for ~2-4 hours every day after work and ~8 hours on non-working days.
Maybe by the time I'm 35 and finally became a decent SRE, I hope that I can do a real work in big company like FAANG. And no one will hire me because I'm too old.
> I'm SRE and I think of myself as a useless lamer compared to the real 10x guys around
The difference is that SRE -- unlike much of AppDev -- gives you leveraged impact. The building blocks and guardrails that an SRE team gives to application development teams can create productivity impact for hundreds or thousands of engineers across dozens of teams. It may not feel like 10x from a banging-out-code perspective, but it sure is from an economic perspective - don't lose sight of that when you're talking about your value with your employer.
FAANG hire college grads with barely any real-world experience, why would you be worse than them if you have been in the industry for 8 years? Further, what makes you think the work you'd be doing at those companies is more "real" than what you're doing now?
I don't have experience with this yet, but being in my mid 30s now, I worry about it of course. But (again granting that I don't have your experience with this) what it looks like to me out there is that there seem to be fewer jobs that make sense for me at smaller more speculative companies, unless it's a CTO type role, but I see "senior" roles at large established companies that are more attractive anyway. (The problem is that I have to go study irrelevant undergrad algorithms in order to do the interviews, but that has been worth it for the jobs so far.)
Just keep learning and don't go stale and stay associated with tech that is going redundant. This is what I have always done and its done me well. I am 48 now and having a blast in my career hacking away on exciting projects.
I'm 55 and am constantly turning down jobs. That said, agism is rampant in this industry. After working with some turtles and fossils I can't say I disagree with it. People become calcified.
I'm not sure if you're looking at large organizations or what, but where I've worked in the midwest (one company with less than 100 employees and a startup with 5), both have had software engineers/developers older than 40. In fact, we sometimes hired people that were specifically older with more experience at the company with less than 100 employees.
Maybe you just need to tune which companies you look at and/or lower you salary expectations. I'm not sure honestly. Just thought I'd try and give you my experience.
No one would ever call me a 10x engineer and I am in your same age group, yet I find that there are plenty of jobs out there for me (or at least there were pre-pandemic). What could explain why I can get interviews and job offers and you cannot? Because it's not age. Maybe stack? I'm all JavaScript. Maybe region? I work remotely (out of state) now but most of my ~5 year career has been in the Bay Area.
I think this is fully explained by 48 Laws of Power, Law #1: Never Outshine the Master. How is it in the best interests of a 30yo engineering manager to hire someone older than him? His best interest is to expand his command using the only way he knows for sure will work which is to hire younger versions of himself.
PS if you just need a job try the huge government contractors
Could this depend on the country?
I'm 35 and this isn't my experience at all in the London area. Every week I have to ignore messages or emails from recruiters, even during the last two months.
Sure, most of the jobs advertised are worse than my current position, but I get the feeling that if I looked around a bit, I wouldn't have any problem getting offers.
I got my first coding job - junior level - when I was 49.
Then again, it did take 4 years of applying for jobs in the industry before I finally found a company willing to take the risk of employing me.
I don't know what my x-ranking is. I know I'm not a rockstar: my sister-in-law gets to tour the world playing bass in a band and my life is nothing like hers.
I'm not on the market, and haven't been for years, but at 43, I haven't seen what you're talking about in terms of hiring.
I can't speak for you of course, but I've known people who at one point couldn't keep the recruiters away who 15 years later can't get a call back, based on not keeping up with the industry.
52 here. I haven't had any problems getting a job. I was never a RockStar, 10x, ninja or anything. Maybe top 10 % in regular companies (Not FAANG). But I tried to stay current for over 30 years. You probably need to have someone review your resume and maybe interview you to see what's going on. Good luck.
Is it possible you priced yourself out? If you were a "ninja" in SF for a decade, and then you're trying to find those kinds of salaries at "regular" software companies elsewhere in the United States, that could be the problem.
>I used to get called a 10x developer, I was also called a rockstar and a ninja and a 100x dev and every other compliment that was hip.
The 10x developer talk is just hype by unscrupulous employers to entice young engineers to have an unhealthy work life balance. Of course they don't tell that to older developers because they would call you on their bullshit.
I know a lot of professional developers that are in their 40s, 50s, and 60s. What keeps these engineers employed is not how great they are technically, but that they are humble, flexible, willing to share their experience, and are social inside and outside of work (large networks).
>Make a backup plan now.
Agreed you should always have a plan B.
Here are a few ideas:
1) Ageism is real no denial of that, but so is racism, sexism, ableism. We all have to work through that nonsense. Don't give up.
2) There are a shit-ton more well paying technical jobs that need coders than just software developer roles, expand your horizons.
3) There are public/private sector employers that need software developers badly who are willing to be flexible. (see NJ needs COBOL developers)
4) Remote developer work is taking off. I think they care less about where you live, what you look like, or how old you are.
> 2) There are a shit-ton more well paying technical jobs that need coders than just software developer roles, expand your horizons.
For sure, I was a "GeoData Manager" at an oil company for a year. The job didn't have programming as a requirement, but I used Python to do my job, and I became super, super productive. After learning a lot about geometry and mapping, I could do a day's work in under an hour. It paid alright for the area, and I didn't have any other experience. I think there's a lot of analyst roles out there that someone with some programming experience could knock out of the park if they don't mind writing a lot of code to read/write Excel spreadsheets, or scrape data from the web, or do any number tasks like that.
NJ wants UNPAID cobol developers. I’ve been researching the cobol market in the last few weeks to see if it was worthwhile and people in the know pretty much agreed that it’s absolutely not worth it. Doesn’t pay well, codebases that run it are hell to work on, and it’s all outsourced to sweatshops in Asia anyway.
Not contesting your more general point per se, but cobol is not a good example of that.
Can't you tweak and prune your resume to look younger? I'm 49 and still 2X ing. Had my 10x moments and think it depends more on the project, company and people for producing at that level.
Get a job as an IT contractor in banking? Most of them seem to be above 40 in my experience and the pay isn't terrible... Might have to wait till after the lockdown though.
Forget CTO. I'm in the exact same boat as the OP, (20 years experience, over 40 years old) and I can't even get an interview for a manager position.
I've been trying to move out of an individual contributor role for a while, but it's always the same story: 1) We need you to build this super-important thing; you're too valuable as a developer right now 2) We're growing fast, we need experienced managers right now (or 2A: Your team is performing at a high level, we don’t need managers) 3) We're cutting back, we don't have a position for you right now. And in my most recent case 4) We're shutting the company down, good luck.
I find most places only want experienced managers, yet the industry as a whole is terrible at providing any sort of career development path for developers.
OP is right - make a backup plan now. If you want to move into management, start laying that groundwork BEFORE you're ready to move on.
Don't interview for a manager. pick a growing startup, ask in the interview about developer career paths, and if management is a separate, lateral, or heirarachical stack (correct answers is "lateral track devs can switch into")
Get good at your job. Get good at the company. Learn the domain and drink the koolaid. And, when the team grows, and they're looking for managers, nominate yourself to begin transitioning. You'll do both jobs and straddle the line for a while but eventually you'll have job experience managing a team.
I think you missed my point entirely. I did those things for 10-15 years, and they led nowhere. Either it's one reason or another from a current employer, or none of it counts with prospective employers all because I didn't already have a manager title.
Sorry, I did miss that. It is unfortunate your employers are not supportive of your career ambitions. I've watched many engineers become managers at PlanGrid, so I know it is possible :)
i.e., have enough saved up to start a startup, and hope to make it big? What happens if it fails? What happens to your retirement, or is the backup plan either continue working till you drop, or rely on kids to carry you thru retirement years?
Tell us more about Spain. I'm considering moving there from Australia as my wife loves Europe. I'm a principal architect in my 30's mainly doing Java / ecommerce / web and pre-sales. Does the weak economy make it hard to find well paid jobs compared to somewhere like London?
> 90%, of what I learn at one job is completely useless for the next one.
That has not been my experience at all (and I've had some pretty major job changes, including lawyer -> software developmer). If I had to put a number on it, I'd say more like 50% of what I've learned at each job is transferable.
If you think of it is "Today I learned how to use $PROPRIETARY_AMAZON_TOOL to set up a new project which will use $PAT to deploy to a $PROPRIETARY_AMAZON_INTERNAL_CLOUD and sets everything up to $PA_MONITORING and $PA_ALERTING in my... etc. etc. etc., you get the idea, then yes, you will feel like what you "learned" is not transferrable.
On the other hand, if you look at it like "Today I learned some best practices for setting up a new industrial-strength projects through the particular manifestation of this tool, learned about setting up monitoring through the particular manifestation of this other tool,", etc. etc., then even though you may have learned via particular local tools, you also learned a lot of stuff that may be useful later.
The question is, let's say you did change jobs and had to learn some new set of tools. Will you learn them faster than you learned the first set of tools? Will you find a new perspective on the issues from learning the new set of tools? The answer should generally be yes. This is broadly speaking why I expect a 5-year veteran to pick things up faster than a fresh grad; OK, sure, you've never "used git", but I expect you've used source control somewhere. You may not "know React", but I expect you to have used something similar enough that you just have to learn React qua React and are not also learning about cookies and the basics of the DOM, etc.
Pretty much the first professional thing I ever did was writing what we would today call a "static site generator" in a tool called Frontier, in its custom programming language, more or less from scratch. On the one hand, completely useless skill, Frontier has been dead for over a decade and was fairly zombie-ish for a good 5-8 years before that. On the other hand... the HTML basics I learned are still mostly good (I think it's fair to say at this point my frameset tricks & skills are not that useful anymore...), and the general skill of knowing how to write a static site generator is almost even low-level trendy right now, even though I would have to write it in some other language, of course.
I dunno what the exact transfer number is. 90% seems high, certainly, but 10% way too low. There's only a small number of tools that are so bad that while working with them, you learn almost nothing about the problem space you are working in because the quirks of the tool completely dominate, and even then I'd submit a lot of it is still attitude.
Almost everything I learn on the job is transferable. I use anything I pick up to build associations with how other things work. If someone is throwing away 90% of what is learned, something is wrong.
The skills I learned as a civil servant - policy development, communications, staff/resource management ... all the way down to document control and filing - have been super-useful and transferrable to both my professional and personal lives.
The skills I developed as I fought, on a daily basis, with the AWS console - the sooner I lose those skills the happier I shall forever be.
Likewise very surprised! I've found that Software Engineering as a field is great for knowledge transferring between jobs -- the ability to design and reason about systems transcends individual languages and tools.
I remember thinking that the internal wiki at anzn was one of it's best workplace features. This was something used by just about every team and rarely needed intervention from internal developers to operate smoothly.
This was prior to the migration though. I can't imagine how much upheaval there was resulting from the migration, language considerations aside. This is probably one moment where tech concerns should have taken a back seat to company stability.
Much of that depends on their justification. It's entirely possible it was made only for broad risk-avoiding reasons due to PHP's reputation at the time (anyone could have "safely" made that decision, you don't need infosec skills to make that call). They could have done a detailed inventory of what they use and found a bad history of bugs like multiple auth bypasses, trivial RCE. Or they might have audited a few of the products themselves and saw the code quality was typically poor and prone to security issues.
Much depends on the Java. Having spent a lot of time on personal projects using the language, it doesn't deserve its reputation -- Java may 'require' an IDE to avoid spending too much time on boilerplate, but modern Java is a good language and the programming experience once you do have that IDE is one of the best, most effective I know.
At the same time, it's absolutely possible for codebases to become "enterprisey" to the point where even the tiniest change takes weeks. Some of the libraries out there use absolutely horrifying patterns.
If you're just coding for yourself, you can avoid those. In a company maybe not so much, and even though the company would be better off avoiding them, maybe they have old code remaining from when such things were considered good.
>Internal deadline: This is a target internal to the team that will not affect anybody outside of the team.
Never in my life have I witnessed an internal deadline. If it came out of your mouth and someone heard it, well done, you've got yourself a soft-deadline. If you haven't said it out loud, it's an expected completion date, not a deadline.
> I think of Go, Rust, Haskell, Erlang, Clojure, Kotlin, Scala as more hardcore languages.
I can tell about Scala: it can be insane hardcore if you want, but it can also be just "a much better Java" as easily - the weird parts are easy to avoid and the normal parts work better. Unless you are a Java veteran and also plan to hire more developers, using Scala instead of Java will save you much time and effort.
And Kotlin is, by design, kind of Scala minus the hardcore.
The problem with Scala is the same as the problem with Lisp. It's too flexible and it ends up having a bunch of dialects. Sure you can only use a subset, but that doesn't fix the problem that the fragmentation makes it hard to find libraries and code examples that only use the subset of Scala you're comfortable with.
> PHP is banned at Amazon due to security reasons, but its successor, Hack, runs a lot of..
Just to be clear, Hack is not PHP's successor. Hack is a fork of PHP developed by Facebook. Hack will not overtake PHP any time soon.
PHP has had security issues in the past. Sure you can do stupid things with it if you want, but modern PHP is security conscious out of the box. Frameworks like Laravel make great default choices about security concerns.
I'm very surprised they banned PHP but not C. In PHP, if you make unsafe code, it's your fault. In C, well, it's still your fault because you could theoretically write secure software in C, but professionals with a decade of coding experience still have memory corruption vulnerabilities in their code. Those bugs just can't exist in PHP and so, after you learn some patterns (such as parameterized queries), the number of serious vulnerabilities one typically finds goes down very significantly. The most serious bug you'll typically find (when written by someone with experience of course) is "I can get application admin" and not "I get server shell access", which is still very bad but not as bad. (Source: am pentester and at work we also do code reviews.)
In general it's not. That said, when you're picking a language/platform, you should start from questions like: "what are the hard problems?", "what are the lowest effort/most sustainable tools for dealing with those problems?", and "what are the tools that the developers have experience using?"
If your whole team are PHP or Rails veterans and you need to get a complex app off the ground fast, now might not be the best time to switch to Python or JavaScript for the server.
As an example, there's a huge ecosystem for Wordpress (PHP), and if it's not a tech company, piggybacking on Wordpress rather than spinning up a new Node.js based stack might be the most long term maintainable choice.
The hatred against PHP seems to be coming from the people that only know the old days of the language and haven't checked it recently. I'd say PHP is quite relevant for any kind of web-apps these days; the language has evolved greatly in many fields, you have a huge community and there are tons of libraries to get anything done. Especially with Laravel, you can get a fully-functioning web application with a full auth flow in a few minutes.
There are places where you might want to think twice about using PHP; especially with cloud-native stuff, I see that there are many libraries that do not really consider supporting PHP, which might make it troublesome sometimes depending on the environment you will use it. However, if there is a need to develop a web app as quickly as possible, I have personally never seen anything beat PHP.
As someone who maintains an extension for PHP, I hate it because the Zend C APIs are an undocumented dumpster fire, and PHP's basic data structure, zend_hash, is a weird hash type with a str/int union key type and an awkward API.
I also hate it because I hit more memory issues (double free, unitialized reads, etc.) in the language and core libs with PHP than any other high level language I'm maintaining similar extensions for.
Python is great, but I think the answer to "develop a web app as quickly as possible" is just going to be whatever the developer has been using and is comfortable with.
A .NET developer might be able to throw up a webapp quicker with .NET tooling instead of picking up Python & Django (or PHP & Laravel), for example.
From what I've seen, I wouldn't say that it's the preferred platform. It's popularity is waning, and the trend is moving to newer, shinier technologies - for many good reasons.
On the other hand, a big portion of the web is built on PHP, legacy as well as greenfield projects. The language has continued to evolve, for example, PHP 7 with stricter type checks, syntax sugar, significant performance improvements.
Looking at Stack Overflow's popular technologies survey ¹, PHP is among the classics, along with Java, Ruby, Node.js, C#, Go.. It's not going away any time in the foreseeable future.
There's a market demand that PHP fills. There are a ton of PHP developers around the world to hire from, and it has its strengths (as well as justified criticisms). It's probably the easiest way for companies who have little to no web development experience to get started.
Short answer is no, there's nothing PHP is really suited for anymore where it's a clear and decisive winner in my opinion (which you're free to ignore, but I think I have a pretty reasonable opinion having worked on a team that uses PHP for current API work).
For web backend response handling PHP is perfectly _capable_, but there are lots of alternatives that are capable. That's a pretty low bar nowadays and shouldn't be a deciding factor by itself. If you're in a situation with an existing investment in PHP and with a team of productive people already capable and willing to work with PHP, it's not an outrageous decision to keep using PHP. PHP 7 and beyond brought a lot of things that makes the language pragmatic and performant. If you can pretend PHP was invented whole cloth as PHP 7 in like 2016 and completely ignore any and all content related to it that's more than 3 years old, it's generally ok to work with now. If there's a PHP-based COTS product you merely need to install, configure and run then that's also fine.
But... if you're planning on creating a high quality modern PHP codebase correctly with full type hinting, unit and integration tests, robust CI pipelines, making design decisions that maintain code quality long term, etc, etc, you're not really gaining anything by choosing PHP either and might actually be losing out on something else outside the realm of backend web request serving that might have come easier if you had invested your time elsewhere. I find it hard to play devil's advocate for PHP beyond making generalized statements that could apply to Ruby or Javascript as well.
I would say that PHP is pretty similar to Ruby and Python. It has a messier history and some inconsistent syntax that people like to complain about. On the other hand it has a huge community, a wide selection of web frameworks, a big set of useful built in functions and libraries, an ecosystem of useful services (for example around Symfony and Laravel) and excellent performance for a scripting language. Both the language and the ecosystem is still developing at a good pace.
In addition there are CMS:es like WordPress, Magento and Drupal with huge market shares that can be used for everything from small blogs where you to pick a theme and get a site up in minutes, to large e-commerce sites up to advanced headless backends for large publishing platforms.
It is declining in use, but the way I see it it's only because there are more alternatives nowadays, not because it's not a good option.
Here in The Netherlands I've seen a lot of recent projects using PHP backends (mostly REST) using Laravel or other frameworks. Front-ends are all React/Angular though.
Plenty of companies are building boring new PHP sites on Magento and making money without being SPAs. At least here in the Midwest, I've noticed quite a few non-tech companies moving their SPA sites away from being SPAs because it was the wrong technology choice for what the site does.
Kudos for the open and honest assessment, I enjoyed reading it. Some feedback for your journey: Drop the focus on languages. Choose one (popular) language and focus on understanding it well. The best thing you can do, is find some open source project with high quality code in that language, and study it. Slowly, how long it takes does not matter. The end result is you will pick up best practices and styles you did not know exist. Concomitantly, study a few frameworks in your chosen language. Ex: If you select python and are doing web development, learn how Django and Flask work. Learn how the requests library or a forms library works. By reading good code, and studying frameworks and libraries that solve peoples real problems, you will build a foundation for how to put together higher quality and longer lasting code. That will not only make you better as a programmer, and better in your chosen language, but you'll start to find that a substantial portion of what you learn will start to transfer.
> Drop the focus on languages. Choose one (popular) language and focus on understanding it well
While I understand this advice, your mileage might vary. I had the exactly opposite approach and did learn a ton of different languages, on the end making it my area of expertise as a compiler developer and language designer. Of course that's niche, but knowing only one language will eventually become a blocking point for every developer, especially in the modern world.
Think of this essay as a barbell, in the investment sense of the word. The beginning and the end of it have some really good insights that can be generalized to a lot of technical / development work.
The middle of the essay (Rules 4-16) are useful observations from Mickey's experience. (I don't know him; I am just trying to relate this paragraph of comments to his experience more explicitly.) This is not a bad thing.
If you are a 1x developer yourself who is looking to improve, I think you want to read treatises like this and try to understand your fellow developer's perspective.
Only truly brilliant developers can give generalized language and database platform advice. The other people who give valuable advice at this level are not developers, they are technology evangelists who have a track record of success helping real developers.
Only when combined with "Rules are made to be broken". Nothing is worse than taking an arbitrary set of rules and turning it into a cult religion.
Other than that and some of the programming language rules (such an opinionated topic) a rare, level headed treatment. Bookmarked for future quotation.
I'm somewhat perturbed that the entirety of the "DevOps" section is advice to get an SRE on your team because an SRE's job is to "be online after hours".
That's an incredibly dismissive and reductive perspective on the expertise and insight that an SRE (or any ops staff)
could bring to a project, and it sounds like this person--or maybe their entire team--is doing a really bad job of owning their own junk.
I'll make a note to be extra wary of looking into any SRE jobs at Amazon if this is how they treat those positions.
This is indeed an incredibly dismissive view, only seeing the SRE as the poor soul you offload responsibility of things running well in production, despite the fact he is likely to have far less insight on what might go wrong and means to fix things.
Being basically in this position (but in a large follow-the-sun team, so I'm fortunate enough to not be paged at night), I can only underline the deep frustration such views can generate. Being paged every 10 minutes, being asked to fix things you have no control over, getting answers like "what? the server is overloaded? it's an infrastructure issue, not a bug in our code" and seeing developers cry when they get a ticket a day, when at the same time each SREs in the team is receiving a dozen, it can lead to some resentment.
A saner approach is to have the SRE as the first line to filter bugs/alerts/tickets out, but being able to call a developer if required. The SRE can also be an active team member with more insight on production constrains and pain points and maybe system architecture recommendations for the whole team. Also, in my opinion, developers should be an active part of running things in production, otherwise the whole dev team can lose touch with reality and lose sight on how well or not things are actually running.
Amazon recruit huge numbers of graduates, so obviously that's a yes. I think their graduate roles pay quite well too.
But if this article is to be believed, they also do things like using 15 different languages on the tech stack (16 to choose from minus PHP because it's banned) and give you the idea that estimates are worthless. If your workplace is doing things like that it's a very bad sign in my opinion.
> they also do things like using 15 different languages on the tech stack
Teams have a lot of flexibility to choose the best tool for the job. It's not surprising that you'd have those options if you're tackling everything from UAV avionics to distributed systems to facial recognition.
It's not surprising that you'd have those options if you're tackling everything from UAV avionics to distributed systems to facial recognition.
Amazon as a company might use them all, but no Amazon team should be choosing between them all (well, they do in so far as you can immediately rule out lots of unsuitable languages for most projects). This guy has worked on two teams so far and appears to be suggesting he's made choices between 15 languages already. That either means the teams he's been on have used wild stacks with endless choice (a reason not to work there) or that he's not correct about the extent of choice he had (and if someone has 5 years at a company and they still don't know that's another reason not to work there).
> Try to push as much logic as possible to the server. If the front end weren’t super complex, I would consider something like Phoenix instead which actually pushes everything to the server.
Sometimes you don't have or don't want a server, but still want to avoid the issue of wedding business logic to the UI.
With web apps my strategy is to treat business logic as a separate library housed in the same project. I'll have a "SomeBusiness" directory and just import it across the project like I would a third party library.
> At first it was pretty simple, but then we got a lot of new frontend requirements and in no time, managing the front-end state was a total nightmare
If there's one thing I envy backend developers it's the fact that they don't receive even half the requirement changes the front-end does.
But I would refrain from pushing as much logic to the server as possible - it's never the better experience for most users in comparison to striking a balance between having it all on the server vs the client.
Maybe I'm being naive but I'm privately nursing this hope that at least for devops / SRE roles people do want folks with plenty of operational experience? I mean I still expect they'd want to see someone keeping up with tech stacks and facile in a modern language or two so the interviewee can fix issues and contribute enhancements but still is a depth of experience at some point really a hindrance rather than a help?
You become more productive by delegating work to the computer.
The better you are at delegating work to the computer, the more productive you will be.
Algorithms are elegant, data is not. If you are not careful, then data will leak into your program and you will end up with special cases for everything.
When this happens, your job becomes a glorified data entry job.
But you can be smarter than that and create abstractions over data that are reusable. And most likely that will involve types too.
Most of this article could be ripped to shreds based on its accuracy. But that isn't the point - he has developed a set of rules and guidance that work for your average developer just slinging code in an enterprise. And while yes, almost everything he says is "wrong" if we push the details... I can see that they are all "close enough" to build a workable framework for your basic 9-5 1x dev.
> almost everything he says is "wrong" if we push the details
Author here. Part of the point was to expose my ignorance and get people to rip it to shreds. So have at it if you want. I've actually learned a good amount so far using this method.
I think there's a hidden assumption that the author didn't expose.
> when I have a relatively small and simple chunk of code that needs to run every once in a while.
I think "run every once in a while" actually means stable requirements.
I think the number of executions per time is irrelevant. Being stable is the important thing.
My theory is that "run every once in a while" is substituting stable requirements because that's what I also see in organizations. What is execute a lot usually has an higher importance for business which also translates to unstable requirements.
Some might say that you should only write one when you need to scale across servers or teams. These projects where everything is a microservice and a single team manages 30 of them are kind of insane.
Not sure I entirely agree on rule 18. My current team probably cares about estimation more than any previous one I've been on, and it's functioned more to keep engineers aware of prioritization and what is blocking. The team leads have definitely made it a point of emphasis to not put pressure on finishing sprint tickets, though.
Erlang is good on business logic and not really good on making something "mathematically nice". It is more in the same place than the one you give to Go/Rust. Low latency good performance and great reliability (these things are linked) for web is a classic use of erlang or elixir.
Erlang (and elixir) are very unfairly bunched with Haskell since they are both functional languages; in practice they are functional in form and in the large, but they make compromises which really make them "a working person's language", not something to live in the ivory tower.
Installing something is easy, learning how to write Elixir/Phoenix/maybe Erlang is the hard part.
Don't ever let "installation" prevent you from trying something, on Mac it's literally "brew install elixir" followed by a command to install phoenix framework.
Follow this advise only if you are currently employed and your employment is extremely safe because your employer is deemed essential or because they are financial strong in the current economy. For everybody else very carefully consider why an employer should hire you when the current economy is failing, programmers generally are very expensive and add very little value to the employer's revenue, and why you are a better value than the other 1000 developers that were just laid off. The economy is never going to be the same and the common suspicion moving forward is that software hiring/practice will also change to compensate.
The article opens with having kids and so they cannot work more than 8 hours a day in a specified time slot. This is an absence of ambition and nothing else. Work-life balance takes some figuring out, which isn't avoidance. I have two white-collar careers in unrelated industries and kids. I have time for both jobs, coding on the side, spending time with my kids, helping my wife prepare dinner, and so forth. I am not unique with this regard.
The bit about How to do Javascript is really bad advise. This is largely the story of my career in the corporate world as a JavaScript developer. The employer is mostly a Java shop because Java developers are easy to find since they are effectively mass-produced by universities. The Java developers have absolutely no idea what to do with any aspect of web technologies aside from Spring MVC. JavaScript is required by the business, so the Java developer fake it until they make it. They still have no idea what they are doing then give up and require a framework. Epic fail. Any other industry would call that an ethics violation, negligence, and that path would land you in a law suit or possibly in jail depending upon the product/industry.
> So we went with vanilla JQuery.
That makes me cry. The programming section is followed by a section on testing that almost makes me angry. Many of the use cases provided for writing tests explicitly mention low confidence on the part of the developer. Horrible advice. The things to test are features and use cases. The software does all that it promises or it doesn't and there should be enough automation to prove that. How you go about that depends upon the product.
The security speaks like somebody who has absolutely no idea what security is. When you have absolutely no idea what security is or why the company would spend so much money on it I too would think everything about it is draconian and worthless. So many software developers seem to think they are well versed in security despite having no such experience, education, practice, interest, or credibility and I have never understood why.
> programmers generally are very expensive and add very little value to the employer's revenue
Then either they are very bad at their job or working at a very bad company. Software companies have some of the highest revenue per employee numbers, compared to other industries.
> The article opens with having kids and so they cannot work more than 8 hours a day in a specified time slot. This is an absence of ambition and nothing else.
Many developers who work 8 hours a day accomplish more than many other developers who work 12 hours a day.
> I have time for both jobs, coding on the side, spending time with my kids, helping my wife prepare dinner, and so forth.
Genuinely curious, how are two full white-collar jobs in parallel even physically possible? Are they remote with completely flexible hours and not full time?
One is part time. My primary employer is a bank about an hour drive away (not rush hour) so I am enjoying a huge gush of extra time due to COVID19.
My part time job is Army Reserves, though starting today it became my primary employer. There are a surprising large number of people who work two professional jobs whether charity, military, freelance, startups, or other.
"Rule 5: When to use Python or Ruby
Python and Ruby seem to me to be pretty similar in that they’re scripting languages and dynamically typed and seemed like the greatest thing in the 00’s. You use them when speed is more important than legibility or debugging. And then Python for ML/AI applications."
Eh? Speed? What kind of speed? Developer speed? Code speed?
Why is legibility in Python/Ruby bad? Bad compared to what?
Why is debugging in Python/Ruby bad? Bad compared to what?
OP here. I know that these rules of thumb gloss over some of the details, and it's this kind of ruthless criticism that I wanted to invite with posting this :)
I'm coming from the perspective of a tech giant, where there are thousands (tens of thousands) of services, and it's often a huge challenge to trace the flow of data through any given system or API and pin down the cause of production issues.
The static typing with Java gives us a lot more guarantees about the data flowing through systems, compared to Python. If I want to inspect some code or debug a production issue, static typing gives me a lot of guardrails. I can be sure that data coming in is of a particular shape, that null constraints are met, etc. Whereas (from what I can tell) it takes a lot of extra work (and more possibility of missing something) to do the same with Python or Ruby. But I haven't ever built a Python or Node service or whatever.
That's what I meant by legibility and debugging speed.
If you define legibility as "can understand the purpose of the code," I do think that Python can be way more legible since you've got so much less boilerplate.
This is poorly titled. A '1x developer' is by definition an average developer. The page is mostly listing basic knowledge that any developer, even a very junior one, should already have. If you aren't aware of the relative strengths and weaknesses of Java, C, and Python, you aren't a 1x developer, you're a trainee.
Anyone know of any better articles truly targeted at '1x' developers? (This isn't snark, it's an invitation.)
> A '1x developer' is by definition an average developer. The page is mostly listing basic knowledge that any developer, even a very junior one, should already have
I'm not sure I agree with that. Why is a "10x programmer with 3 years experience" better/worth-more than a "1x programmer with forty years experience" if the output of the latter is higher?
Do I just not understand what you mean? This sounds too much like internet points or something.
I have always thought a "1x" or "10x" developer referred to their output of business features.
Or put simply, if all of your stories were scored equally, this is the number of stories your developer can do in some unit of time.
Now, I know there are probably problems with this, but it seems mostly right, and people who I can give bigger tasks to, are usually the programmers who have done more practice/had more experience.
This reminds me of something.
When I was in school, one of my best friends was good at drawing. People would ask him all the time, "How did you get so good at drawing?" and he would say "Practice!" and they would say, "No no no! You must get it from your Mother because she is good at drawing! You are so Gifted!"
I think it was the practice, and I think programming's the same thing: That practice makes you better.
> Anyone know of any better articles truly targeted at '1x' developers? (This isn't snark, it's an invitation.)
If you think you've just been so low-output for so long it's making you dissatisfied and you don't know how to study/practice anymore, getting a mentor can help you.
This can really help if you've had a nontraditional career, since popular articles are (get this) for the populous, so it can really be hard to figure out what to do without going backwards if you can't look outside and see someone like you but a little further along in the direction you'd like to grow.
I'm talking about very basic background knowledge of general software engineering. Yes, a professional frontend developer should have at least an elementary understanding of the differences between the major programming languages.
An expert frontend developer will necessarily be competent in many languages, and might be competent to, for instance, contribute code to the Qt project.
I can see the value in the Project Management section of the article, as that's the sort of 'soft' topic that will be new to, say, a fresh graduate. If someone doesn't know the first thing about programming languages, though, they're a long way from the standard of a developer.
In the study that lead to the "10x developers" term. 1x developer was not the average, but the least good (because they still were able finished the task). You can't measure against the "worst" because they aren't able to provide a deliverable.
I think it should be the contrary: SQL by default, no-SQL if you have a specific need and know what you are doing.