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.
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.
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.
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.
>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
