Live data from Hacker News

Rules of thumb for a 1x developer

muldoon.cloud

391–400 of 505 posts

Re: Rules of thumb for a 1x developer

#391
post #114

> And what I have found is that most – say, 90%, of what I learn at one job is completely useless for the next one. Then the problem isn't with what's being learned. The problem is that the author lacks a framework for generalizing and internalizing the lessons learned. Letting 90% of lessons learned on the job go to waste later in life is going to lead to a very difficult career path. Later... > Compounding is a pre…

OP here. You're spot on. Both in calling out that this is a solvable problem (not a fact of nature) and that writing is probably a pretty good way to get started. That was definitely the idea with putting up the blog.

I came up with the 90% number not because I have any real data on this, but as a way to provoke myself to challenge some assumptions. Earlier on in my career, it was easier to tell myself the story that everything I learned, all the hours I spent doing stuff, were all part of a bigger narrative. That it would all build upon itself in a one-directional way. Even if I forgot specific facts, I'd still always be learning and growing in one way or another. I'd be developing critical thinking, learning how to learn, moving to higher levels of abstraction, pruning out useless knowledge and strengthening core insights. That kind of thing.

That was actually a pretty useful mentality, and still is in a lot of ways. It gave me the confidence to do a bunch of career changes (like I think I mentioned in that section of the blog) because I did believe that I was drawing lessons from each successive career area to the next. And there was a lot of truth in that.

However.

At the end of the day, as a developer, I'm certainly not doing Leetcode or Kaggle all day. The majority of what I've spent my time learning has been very specific knowledge: learning the components and business logic in specific systems, getting comfortable with internal tools and processes, getting to become very familiar with some subset of all the company code, working with clients and dependent teams and internal customers. I do believe that being a tech giant can make the situation worse in that regard since the specific problems tend to be so narrow. But my hunch is that it's still the norm for developers.

I'll put things in a different perspective. According to a lot of studies, doctors get worse at their jobs on average over time (link: https://hbr.org/2017/05/do-doctors-get-worse-as-they-get-old...). Most of what they learn on a day-to-day basis is very specific, time-bound knowledge (specific patient info, office info) rather than general-purpose lessons about medicine. By going for the 90% number I was trying to push myself to consider that that sort of effect is the norm (in programming and elsewhere) in contrast to my earlier notions about "constant generalization."

I think this number can be changed but like you mention, it requires an amount of deliberate effort like writing that just hasn't been baked into my usual routines.

Re: Rules of thumb for a 1x developer

#392
post #294

I hate the notion of "10x developer". 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 f…

The majority of developers are 0.1x or worse. It's Price's law. For every passionate and productive developer, there are 10 more who coast and do the bare minimum to not be fired. This has been true in every single organization I've been part of.

And the majority of these have so little presence in places like this, that its easy to forget that they exist at all.

Heck, when I joined my first large-team software development project at work, I was flabbergasted at how many "numb-nuts" there were. This is because the online world of armchair authorities pretended those people didn't even exist, and thus raised the bar so high that it made me believe I wasn't even worthy of owning a keyboard.

Re: Rules of thumb for a 1x developer

#393
"Rule 5: When to use Python or Ruby Python and Ruby seem to me to be pretty similar in that they’re scripting languages and dynamically typed and seemed like the greatest thing in the 00’s. You use them when speed is more important than legibility or debugging. And then Python for ML/AI applications."

Eh? Speed? What kind of speed? Developer speed? Code speed?

Why is legibility in Python/Ruby bad? Bad compared to what?

Why is debugging in Python/Ruby bad? Bad compared to what?

Frankly...this feels like a 0.5x article to me

Re: Rules of thumb for a 1x developer

#394

"To replace out MediaWiki with a Java-based alternative (XWiki) ended up taking a total fo 24 dev-years over 4+ calendar years for the team, not counting the interruptions to pretty much every other team at Amazon as their pages were getting constantly migrated and un-migrated" I would love to hear more about this. I'm guessing that's a cost of at least $4M? How was this approved? How did they allow it to continue fo…

Re: big company vs small -- Small companies fail all the time; projects like this pare more prevalent at big companies because it doesn't (always at least) kill them.

Re: Rules of thumb for a 1x developer

#395
post #388

Earlier quoted context omitted.

To be completely frank, I'm seeing less and less reason to use traditional sql databases. MongoDB offers the ability to make sql queries and even has Acid transactions. Everything SQL can do, it does without slowing down when dealing with big data. The only thing it doesn't offer an efficient solution for is something SQL can't do either, and that's advanced search engine capabilities like Elasticsearch provides. Som…

> MongoDB offers the ability to make sql queries and even has Acid transactions. Everything SQL can do, it does without slowing down when dealing with big data. The only thing it doesn't offer an efficient solution for is something SQL can't do either, and that's advanced search engine capabilities like Elasticsearch provides. You seem to be looking at this solely from a perspective of what kind of queries you can ru…

You made the point I wanted to make without sarcasm. Thanks :-)

Re: Rules of thumb for a 1x developer

#397
post #285

Earlier quoted context omitted.

I'm in my 40s in the SF Bay Area and recently landed a new software development job. The process took several months. My initial interviews were disastrous; it had been many years since my last job search and I didn't know I wasn't prepared for the "leetcode era". Drilling on "leetcode medium" problems with a time limit got me to the point where I was at least in the game that's being played nowadays. It wasn't prett…

I'm 40 and a developer for 15 years and didn't make it past Amazon's initial code assessment. One of the problems was a floodfill algorithm, which I've never used before. Couldn't quite figure it out on my own, but found the answer in Google in about 5 minutes, which is what I would do in real life faced with this problem. I don't understand the purpose of asking people to memorize a bunch of algorithms they will pro…

I got cut from an Amazon phone screen by not being able to cough up various Minesweeper algorithms off the top of my head. (Also something I've never used before or since.)

Thankfully, at the same time (this was in 2011), I was also in the process of interviewing for a startup that treated me like a real person with individual skills and experiences of value. That interview process went a lot better, and did result in me getting hired.

(And Amazon recruiters still pester me to this day, despite me having little interest in working for them.)

Re: Rules of thumb for a 1x developer

#398
post #244

Earlier quoted context omitted.

> They're cheaper, willing to work longer hours 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.

Salaries over time are rarely based upon prior experience or knowledge; they are the function of normal annual salary adjustments combined with 5-20% increases when job hopping. Which is, if you perform well, roughly equivalent a 4% annual compound interest. As they say, compound interest is king - companies are just not willing to swallow the fact that the compound interest is in this case working against them. And…

Salary isn't a function of time- it's a function of perceived value and leverage.

Re: Rules of thumb for a 1x developer

#399
post #373
post #216

Earlier quoted context omitted.

Keep in mind stories like the wiki one are anecdotal (meaning it's not representative of all projects), and in fact this is covered in both Patrick's tweet thread and Dan Luu's linked essay ( https://danluu.com/sounds-easy/ ). So while they do their best to not have _every_ initiative go this way, large companies - even the mythical FAANGs - will inevitably have moments like this wiki debacle, and they need to be abl…

Dan and Patrick's accounts of bigness are precisely as anecdotal. I would love to have empirical data about this whole business. I have no idea how you would collect it.

Nobody makes fun of Coca-Cola for having 80k employees. "What do they have so many employees for? All they do are come up with combinations of sugar, water, and packaging. They don't even do the bottling!"

Re: Rules of thumb for a 1x developer

#400
post #363

"Rule 11: Which database technology to choose: Choose SQL when you need to do ad hoc queries and/or you need support for ACID and transactions. Otherwise choose no-SQL" I think it should be the contrary: SQL by default, no-SQL if you have a specific need and know what you are doing.

I feel like this is a case of "probably shouldn't have a default". SQL should likely be a default consideration but if you're going to say "time to build an app, let's spin up a (insert thing here) to store data" rather than "Let me take some time to consider what my data looks like and select a data persistence strategy accordingly" then you're probably going to wind up also writing a "how my team migrated from to because man did not fit our use case at all" article.

Although I guess if you need blog fodder...

Post reply on HN