I agree in various degrees with most of the letter, except one point I strongly disagree: compare with others.
First, comparing to others will motivate you to get better, have a positive target you want to reach: "I want to be as good as Jake" was my model when I was in college, Jake was at that time the best IT expert I met for a decade.
Second, because you need to know where you are and what is going around you. You need to know your peers and how you are qualified versus them, how productive and appreciated you are and how are you paid. You may be motivated to do something when you find the new colleague still in college is earning as much as you do after 10 years just because the company wants to promote women and "reverse the wage gap", so they give female college students positions and wages equal or higher than top rated senior engineers that are male. Just saying, I saw many such cases.
I totally agree. Eventually you will compete with your peers for attention, housing, world resources, etc. It is vital that you compare yourself to other. Of course, comparison should not happen in a way that leads to jealousy, but rather a mindful choice of "I want to become good at this" or "I want to stay out of this".
And I disagree with your disagreement. The following phrase in particular gives me pause.
You may be motivated to do something when you find the new colleague still in college is earning as much as you do after 10 years just because the company wants to promote women and "reverse the wage gap", so they give female college students positions and wages equal or higher than top rated senior engineers that are male. Just saying, I saw many such cases.
I don't know you, but I have known a number of people who said things that sounded like that. (With different concretes.) They were unable to productively work with people who they thought had been unfairly promoted. Their resentment hindered their productivity. And I found myself in disagreement with their self-image about how good and deserving they were.
It didn't matter whether I privately agreed or disagreed with the promotion that they complained about. The fact that they were looking around the workplace and thinking about that lead to the negative behaviors for themselves. And their negative behaviors added toxicity to the workplace.
For this reason and others, I prefer the advice in the letter. Comparing with others might work out in the short run, but in the long run it doesn't seem to work out in our profession.
Totally agree. I've always found it easier to work with someone who was unskilled but eager over someone who had the skills but was deliberately dragging things down through resentment.
Just be selective, only compare yourself to others whom you know are doing worse.
j/k of course, I agree, comparing yourself to others is not beneficial. Compare yourself to your past self is more motivational. There's a good chance that today you are better at whatever it is you chose to do than last year.
Furthermore, I'd also advise parents not to compare their children to other children. (it happens)
Then you prefer to live in a bubble and not having any idea how you perform versus others? It's a great way to become the last of the pack and get fired while believing you are so much better than yourself a month ago.
I wish there was a better way to phrase this. I understand the spirit of this advice but in software we don't get better compilers if we stick with the first compiler that gets invented.
I've reinvented many things simply to learn how they work. Sometimes I get ideas about how to do things better. Sometimes I do it for the challenge (I bet I could do that). Sometimes I find that I can cut out 2/3 of the code, half the features, and get a system that is easier to maintain and remove errors from.
It's hard to become a better software engineer if all you do is glue together libraries. It's hardly ever appropriate to write your own database from scratch in a production application. But it's also hard to understand how to write your own database if you never write one yourself.
That isn't NIH. In fact it is often the opposite of NIH. It is a pre-requisite of becoming a true expert in the technologies that you are using.
NIH is writing your own database and using it in production.
But understanding how to write a database makes it easier to understand why your existing database works the way it does, and what its quirks should be.
For example suppose that you have a slow query. You EXPLAIN ANALYZE to get a query plan. Now what? It really helps if you can say, "What would a program to do this look like? How fast would it be?" And then be able to say, "And if I was to write a program to do this, how would I do it? How fast would that be?" And then if the second is faster you can ask, "How can I get the database to do what I think it should do?" (Hint, in most databases with temporary tables and indexes on them, you can force your desired query plan to within a factor of 2.)
That exercise really helps in optimization. But that exercise is only available to people who know how a database actually works.
This one stood out to me too. One of the few things that has kept me going as a software engineer, both professionally and as an 'enthusiast', has been exactly this 'reinventing the wheel'. Just building stuff. Intentionally not researching how chat bots work and trying it myself first. Avoiding frameworks and starting with a simple HTTP server. And making all the mistakes I could've avoided.
Sure, if I want to get a job done I avoid this, or don't bill. And sure, there are plenty of programmers who get stuck in a 'local optimum' with their homebrew solutions.
But treating programming / software 'engineering' as something that is also about fun and learning and discovering rather than just income and career, has kept me from burning out and made me better at my job.
> Intentionally not researching how chat bots work and trying it myself first. Avoiding frameworks and starting with a simple HTTP server. And making all the mistakes I could've avoided.
Excellent ideas for learning about how those systems work. Honestly there's no better way. The problems arise when people assume their roll-your-own HTTP server is a good idea to deploy in prod.
Unless there's a really good business reason, take the knowledge you gained from that exercise to work, but leave the code at home.
I’ve thought of it like this. The “avoid NIH” rule guides your default attitude on any project you are getting paid to produce. You have limited time, resources, focus, or opportunity for your effort to make a difference.
The history of the Erlang language is a good example [0]. Ericsson engineers did deep dives into over 20 existing languages over three years before proving to themselves a new language needed to exist.
Totally agree that NIH applies to how you make decisions as a professional working for an organization. For personal projects, carte blanche.
There is knowledge, and intrinsic knowledge. And only experienced knowledge, becomes intrinsic knowledge. As in only catastrophes you witnessed yourself, will "traumatize" you enough to integrate counter measures into your behaviour.
Just reading about stuff does nothing.
Thus we repeat history to learn from the nightmares of our grandparents.
I don't have a problem with reinventing the wheel if that's what you know you're doing. Other people have already pointed out the many good reasons why you would want to do that. What I do have a problem with is people who reinvent the wheel because they couldn't be bothered to check if someone had already invented it.
I remember a poster illustrating this point. It was essentially the iconic "evolution of man" scenario but for the wheel; the caption was along the lines of "Sometimes It's Necessary".
20 comments
[ 4.8 ms ] story [ 67.6 ms ] threadFirst, comparing to others will motivate you to get better, have a positive target you want to reach: "I want to be as good as Jake" was my model when I was in college, Jake was at that time the best IT expert I met for a decade.
Second, because you need to know where you are and what is going around you. You need to know your peers and how you are qualified versus them, how productive and appreciated you are and how are you paid. You may be motivated to do something when you find the new colleague still in college is earning as much as you do after 10 years just because the company wants to promote women and "reverse the wage gap", so they give female college students positions and wages equal or higher than top rated senior engineers that are male. Just saying, I saw many such cases.
You may be motivated to do something when you find the new colleague still in college is earning as much as you do after 10 years just because the company wants to promote women and "reverse the wage gap", so they give female college students positions and wages equal or higher than top rated senior engineers that are male. Just saying, I saw many such cases.
I don't know you, but I have known a number of people who said things that sounded like that. (With different concretes.) They were unable to productively work with people who they thought had been unfairly promoted. Their resentment hindered their productivity. And I found myself in disagreement with their self-image about how good and deserving they were.
It didn't matter whether I privately agreed or disagreed with the promotion that they complained about. The fact that they were looking around the workplace and thinking about that lead to the negative behaviors for themselves. And their negative behaviors added toxicity to the workplace.
For this reason and others, I prefer the advice in the letter. Comparing with others might work out in the short run, but in the long run it doesn't seem to work out in our profession.
j/k of course, I agree, comparing yourself to others is not beneficial. Compare yourself to your past self is more motivational. There's a good chance that today you are better at whatever it is you chose to do than last year.
Furthermore, I'd also advise parents not to compare their children to other children. (it happens)
I wish there was a better way to phrase this. I understand the spirit of this advice but in software we don't get better compilers if we stick with the first compiler that gets invented.
I've reinvented many things simply to learn how they work. Sometimes I get ideas about how to do things better. Sometimes I do it for the challenge (I bet I could do that). Sometimes I find that I can cut out 2/3 of the code, half the features, and get a system that is easier to maintain and remove errors from.
It's hard to become a better software engineer if all you do is glue together libraries. It's hardly ever appropriate to write your own database from scratch in a production application. But it's also hard to understand how to write your own database if you never write one yourself.
You just took NIH to a whole new level.
NIH is writing your own database and using it in production.
But understanding how to write a database makes it easier to understand why your existing database works the way it does, and what its quirks should be.
For example suppose that you have a slow query. You EXPLAIN ANALYZE to get a query plan. Now what? It really helps if you can say, "What would a program to do this look like? How fast would it be?" And then be able to say, "And if I was to write a program to do this, how would I do it? How fast would that be?" And then if the second is faster you can ask, "How can I get the database to do what I think it should do?" (Hint, in most databases with temporary tables and indexes on them, you can force your desired query plan to within a factor of 2.)
That exercise really helps in optimization. But that exercise is only available to people who know how a database actually works.
Sure, if I want to get a job done I avoid this, or don't bill. And sure, there are plenty of programmers who get stuck in a 'local optimum' with their homebrew solutions.
But treating programming / software 'engineering' as something that is also about fun and learning and discovering rather than just income and career, has kept me from burning out and made me better at my job.
Excellent ideas for learning about how those systems work. Honestly there's no better way. The problems arise when people assume their roll-your-own HTTP server is a good idea to deploy in prod.
Unless there's a really good business reason, take the knowledge you gained from that exercise to work, but leave the code at home.
The history of the Erlang language is a good example [0]. Ericsson engineers did deep dives into over 20 existing languages over three years before proving to themselves a new language needed to exist.
Totally agree that NIH applies to how you make decisions as a professional working for an organization. For personal projects, carte blanche.
0: https://www.erlang.org/course/history
>There is no point in reinventing the wheel.
There's a difference in a wheel made out of stone and one made of carbon fiber.
Something very much like this: shorturl.at/lpQVW