Rules of thumb for a 1x developer
muldoon.cloud
muldoon.cloud
I think it should be the contrary: SQL by default, no-SQL if you have a specific need and know what you are doing.
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.
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 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.
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.
And Mongo's slow, too.
Although I guess if you need blog fodder...
Picking it as the default would make us wrong less often.
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.
The issue with SQL is that the DB needs to be designed first. But when it is done correctly, the advantages are numerous.
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.
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?
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.
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.
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.
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?
No.
What about forgetting about these X and instead do what seems like fun on the spare time :-)
Friends, family, side projects / books if you want to -- but then because you want to? Life is short
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?
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.
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.
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.
It is just not true that someone always runs the math and then decides by weighting pros and cons.
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.
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.
Getting documentation off google docs on the other hand seems impossible from a behavior standpoint :(
("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")
https://twitter.com/patio11/status/1255371954443505665
It's always satisfying to read reports from the trenches demonstrating the exact opposite.
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.
I would love to have empirical data about this whole business. I have no idea how you would collect it.
- 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.
I think Coca-Cola is a pretty bad example.
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).
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.
I mean, it gave a lot of people something to do (and get paid to do) for 4 years. There's your answer, most of the time.
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
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.
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.
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'.
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.
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.
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 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.
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.
Is there a right way to go about this? This is something I need to start doing, personally.
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.
During work hours stay away from:
* HN
* Any other thing constantly distracting you and taking away your attention from your job
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.
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."
-you can get more done if you avoid addictive black holes for attention
--if they don't want you playing around they should pay you more than the salary you agreed to work for
---yup, still getting paid the same. company is getting theirs, go get yours (I think this reply was actually sarcastic)
----how do you live with yourself
-----if you have integrity you're dumb
------most people actually work for money, you'll probably get found out eventually otherwise
-------you won't get found out if you embed yourself in a big enough company where you can hide, rinse and repeat
It sounds less like an argument to pace one's self, and more like cynical entitlement.
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.
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.
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.
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.
yup, dang already deleted my comment on Who's Hiring. what's your issue with engineers being able to compare processes between companies?
I'll try to come back and reply to your posts in this thread later.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
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.
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.
https://www.theguardian.com/technology/2014/apr/24/apple-goo...
I don't think this significantly affects what I wrote above.
> "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!
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!
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.
All of my raises and promotions came from results that exceeded expectations.
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.
After the first week, yes.
Whether you are still being paid the same after a year depends on you and your negotiation skills.
Or you can be equally productive, work less, and make the same.
In a world that complains about not having enough time, it's an option that many people seem too timid to take.
> 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.
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.
Maybe you're a 2xer though.
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 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.
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.
> The exception to this is JS
JavaScript is beautiful. You're crazy.
I loved Ruby until I inherited a project that was poorly written Ruby.
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.
Imo toxicity is independent from productivity.
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.
There are also devs whose technical skills have outpaced their social skills temporarily, but they get better later...
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.
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.
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.
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 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.
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")
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.
Make a backup plan now.
Could this be why? Desperation has a way of putting people off?
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.
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.
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.
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.
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'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.
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.
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.
> What did you work on during those years?
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.
Please don't, you have no relevant information so your speculation isn't helpful.
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.
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.
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).
I won't either. But I was at one company about 13 years, another about 8, and just over 10 at my current one.
Turns out that it really is hard to get a job when you don't already have one.
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.
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.
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.
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 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.
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.
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.
Edit: typo
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.
I understand that for a big company they need something standardized to process a large number of candidates.
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'
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.
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.
If I didn’t have any other option besides the standard r/cscareerquestions “Learn leetCode and work for a FAANG” , I would.
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?
Not even five years ago this style of interviewing was looked down upon by most.
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.)
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.
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.
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.
Out of curiosity - don't companies take a pass on older candidates because they expect them to ask for a higher salary than the younger ones?
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 $$$.
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 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.
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
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).
(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.)
If not, I'm going to ask the next one to flag me in their system, if that's possible.
And I really have no desire to work for that type of company. Love it as a customer, but not my cup of office.
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.
I know that feeling!
Truer words rarely spoken. Tech is Logan's Run, No Country For Old Men.
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!
Why is that a negative signal? The company has the opportunity to get top talent temporarily down on his/her luck for a reduced rate.
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.
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.
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.
Standard: not saying it's fair or endorsing this, explaining how people think and feel about it.
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.
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.
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
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.
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).
- 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.
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.
Spoiler: because you assumend he can find a job bevause he's desperate.
Your problems are not other people's.
I'm almost 40 and are constantly getting harassed by recruiters.
My mate in his 60s not long ago got hired for a software developer role, and easily at that. Two interviews and he got an offer.
Another mate near 40 stepped back from manager type role into a developer role, and his age is not an issue.
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.
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.
Only result of this is to repeat mistakes over and over again...
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.
Shouldn’t minimize the reality of getting old.
https://www.cbs.nl/en-gb/news/2019/19/average-age-of-first-t...
and
https://www.cbs.nl/en-gb/figures/detail/37744eng
the latter has underlying data for which you can extract %ile parent age. To save you the time, by parent age 40 it's under 10%ile.
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.
And I really like working remotely. If I lose this job for whatever reason that's Plan A, not the backup.
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.
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.
I'm saving as much as I can. The end is nigh.
Can't you just lie about this? It's none of their business.
Or tell white lies -- kids, but "pretty old" or "at college" or whatever.
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.
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...
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
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. :-)
- What are your hobbies?
- What drives you?
- Where do you see yourself in five years?
- Would you be willing to work long hours often?
- Can you work in the USA?
And so on.
There's so many questions that are legal to ask but for which an honest answer would reveal private information.
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!
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.
Is there something you aren't telling us?
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...
Good luck!
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.
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.
That said, if you're an older dev that hasn't kept up with the times, I'm prob not going to hire you.
I even work in SV :)
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 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 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.
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!
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.
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.
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.
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.
PS if you just need a job try the huge government contractors
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 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.
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.
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 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.
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.
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.
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?"
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.
1. Experience without knowing the latest stack is useless for a pure developer role.
2. Leaning into the deep memory of past failures is more consistent with a technical lead, which is one of the "other" growth paths.
C - first released 48 years ago.
Python - first released 30 years ago.
C++ - first released 35 years ago.
C# - first released 20 years ago.
VB - first released 29 years ago.
Javascript - first released 24 years ago.
PHP - first released 25 years ago.
SQL - first released 46 years ago.
R - first released 26 years ago.
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.
> 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.
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.
Discrimination is real, and many people in the Valley pretend it doesn't exist when it conveniently benefits, or doesn't affect, them right now.
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.
And you can end up with an amazing amount of freedom on technical choices, etc.
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.
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.
You gotta see your work as an investment and not as an exchange of time for money as seems to be the governing consensus
I'm so sick of the tropes and stereotypes if one is serious about wisdom and knowledge one knows how to start at first principles
It sounds like you're playing to lose whereas if you've learned anything in all these years it's that if you don't like what's being said...
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.
> 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.
How about everyone else? Closer to 10% or 50%?
50% sounds about right to me.
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.
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.
Oof. To be fair, Java is probably way easier to code review.
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.
What makes it great is everything around it - from second to none JVM, range of state-of-the-art developer tools to the best library ecosystem.
Run away!!! (And I like Java!)
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.
This is the most surprising claim, to me. I would have flipped the ratios. Even the most radically different jobs I've had shared more than 10%.
90% of the facts that my boss tells me are useless for the next job, true, but 90% of what I learn are not the facts which are told to me.
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 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.
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 have never even looked at the php site or docs, but I am curious.
In this day and age, is there a subset of Apps that PHP is suited for?
Also depends on the team, if you have a PHP team and it's a web project, you probably want to use PHP.
I myself have spent a lot of time weighing in the pro's and cons of SPA vs. Non-SPA for a recent project.
It's not like all new projects are SPAs.
Pretty easy to setup, and preview the first index file.
Took about 1 hour, starting from 0 knowledge, though I am well aware of the NodeJS ecosystem.
To me, even .NET is a bloat, compared to Node.
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.
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.
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.
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.
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.
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.
It's "preferred" as in tons of people get a lot of good work done with it quickly, but wouldn't go out and proselytize how "great" it is or isn't.
PHP is just a tool. A fairly old one at this point. But it still holds up to most of today's standards and is a constantly evolving language.
It's not the hipster language of choice though.
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.
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.
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.
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.
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.
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.
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.
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.
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).
From my experience, scrum is better. The idea is that you can measure progress and you can learn from mistakes with scrum.
Kanban doesn't help in that regard.
Also, a good scrum master will tell you some things:
- a successful sprint is one in which not all stories were finished, because the goal was ambitious
- do not sweat over spill-overs; they happen all the time, it's not the end of the world as long as you work 8h/day really focused and give your best
I know that in the US you got modern slavery with insame working and commuting hours, but life is decent in places like Europe.
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.
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.
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.
> Rule 10: When to make a microservice
> I would use a microservice when I have a relatively small and simple chunk of code that needs to run every once in a while.
Isn't this wrong? There's no reason a microservice should just run once in a while. It also creates a lot of complexity for a simple chunk of code.
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.
> 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.
4. When your spacecraft needs to get the correct mission elapsed time from the launch vehicle.
https://arstechnica.com/science/2020/02/boeing-acknowledges-...
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.
He can call himself 1x, but if he can stop just 1 colossal failure like that he can easily become 10x.
"If you delegate all your IT security to the InfoSec, they will come up with Draconian rules"
install = install Erlang + install Elixir + install Phoenix
Well.. I'll stick to Node + vanilla JS
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.
Sometimes though installation is a real pain. (For ex. OCaml/OPAM on Debian)
Is this a joke? Why write such nonsense when you must know you don't know anything about the subject?
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.
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?
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.
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.
Generally very shallow advice and poor or no discussion on why.
Fuck sake.
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?
Frankly...this feels like a 0.5x article to me
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.
Anyone know of any better articles truly targeted at '1x' developers? (This isn't snark, it's an invitation.)
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.
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.