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.
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.
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.
This is probably my own fault, but I feel pressured to be constantly doing something towards programming. I feel like I should either be reading a book or starting a project.
I have 10+ programming books where I just finished reading one of them and I have way more unfinished projects than I could count.
It's reassuring to see the push-back against the 10x developer idea, I'm starting to feel less guilty now when I spend my free time NOT on programming.
Something that has also helped me out is picking a project to do, and ignoring everyone else's projects. I would always get pulled away with what I'm starting to work on because I see someone using a new technology or doing something unique. When I would see that I would change up my project because I felt it wasn't good enough or that it wouldn't make me a 10x developer. Now I'm just trying to focus on what makes me happy and what I find enjoyable to work on.
I want to ask though - the author works at Amazon and considers himself a 1x developer. What does that mean for everyone else who doesn't work at Amazon or a FAANG company? Is a 1x developer at a FAANG company a 10x developer elsewhere?
I 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.
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.
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?
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.
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.
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.
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 :(
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
("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")
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.
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.
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.
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.
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.
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.
Is there a right way to go about this? This is something I need to start doing, personally.
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.
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.
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.
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.
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...
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!
yup, dang already deleted my comment on Who's Hiring. what's your issue with engineers being able to compare processes between companies?
> 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.
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.
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 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.
There are also devs whose technical skills have outpaced their social skills temporarily, but they get better later...
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.
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.
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.
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.
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.
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.
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!
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.
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.
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!
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.
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 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 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'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.
And I really like working remotely. If I lose this job for whatever reason that's Plan A, not the backup.
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.
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!
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.
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 :)
Truer words rarely spoken. Tech is Logan's Run, No Country For Old Men.
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.
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.
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.
I'm saving as much as I can. The end is nigh.
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.
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.
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.
I have defined my advantage should be experience, wisdom and maturity. I try to deliver something to my managers that they just can't get from a developer that is very bright but has just couple of years of experience. I try to spend more and more of my time learning and deliver with less time expenditure.
Also, don't get discouraged when you don't get a job somewhere because you are an older guy. You should be thankful that you did not get the job, probably it would be a dead end anyway.
You don't need every place to accept your age. You just need one -- one where you will feel at home and be happy offering your services.
That scares the hell out of me. I started working in IT at 22 and now I'm 30.
I'm SRE and I think of myself as a useless lamer compared to the real 10x guys around. It gets heavier every year.
I got bagdes CCNP/OSCP/RHCE/CKA/AWS DevOps Pro/etc only to confirm that I know at least something. (I don't tell anyone about them so I don't become known as a paper tiger.) On my way to CCIE.
I study things and write code for ~2-4 hours every day after work and ~8 hours on non-working days.
Maybe by the time I'm 35 and finally became a decent SRE, I hope that I can do a real work in big company like FAANG. And no one will hire me because I'm too old.
Could this be why? Desperation has a way of putting people off?
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.
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...
PS if you just need a job try the huge government contractors
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.
Then again, it did take 4 years of applying for jobs in the industry before I finally found a company willing to take the risk of employing me.
I don't know what my x-ranking is. I know I'm not a rockstar: my sister-in-law gets to tour the world playing bass in a band and my life is nothing like hers.
I 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.
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.
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.
Is there something you aren't telling us?
> 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%?
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.
50% sounds about right to me.
Oof. To be fair, Java is probably way easier to code review.
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.
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 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?
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.
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.
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.
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.
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.
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.
Also depends on the team, if you have a PHP team and it's a web project, you probably want to use PHP.
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.
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.
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.
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.
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.)
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.
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.