My “Investment Mindset”(blog.pragmaticengineer.com)
blog.pragmaticengineer.com
My “Investment Mindset”
https://blog.pragmaticengineer.com/the-investment-mindset/
28 comments
Getting better at algorithm/data structures has made me a much better programmer. People say "oh I'll never use that" but doing graph and tree problems got me much better at writing pure recursive code. I instinctively know how to write algorithms now that are much more performant.
Last night I decided to write a React component that can render formatted JSON in the browser, with collapsing etc...it took me about 4 hours. There's zero chance I would have been able to do that without that experience. I would have just looked for a library to do it.
So yeah, I highly recommend it.
Last night I decided to write a React component that can render formatted JSON in the browser, with collapsing etc...it took me about 4 hours. There's zero chance I would have been able to do that without that experience. I would have just looked for a library to do it.
So yeah, I highly recommend it.
But isn't using a library generally better idea than to roll your own stuff ?
At least that is my approach to programming.
At least that is my approach to programming.
Whether or not using a library is better is highly dependent on the problem you're trying to solve.
Sometimes there isn't a library. Sometimes the library hasn't been updated in years. Sometimes you need only 10% of a library's functionality but have to import 100% of it. Etc...
But the problem - and I say this as someone who was like this for years, is when you reach for a library before attempting to actually understand the problem or what the library is doing. Then it's just Google driven development. And you better hope that the library has example code you can copy and paste and modify to fit what you're trying to do, because when you don't understand anything about what's going on under the hood that's mostly what you're going to do.
Like I said, I was like this for a long time. Libraries were a black box to me. I still work with people who are like this. In the article this comment thread is about, he talks about how he released an open source library for doing advertising on Windows Phones and got tons of Issues from other "developers" wanting new feature/changes.
Their mindset isn't "I could add this myself" or put in a pull request, this guy who I am relying on to do a part of my job for me -for free- needs to fix this.
Ultimately, you don't grow as a developer when you think like this. You don't grow to become the kind of developer that makes libraries. It also gets harder and harder to be effective the more senior you get. Because if you need a feature the package you're relying on doesn't have, you're SOL.
Sometimes there isn't a library. Sometimes the library hasn't been updated in years. Sometimes you need only 10% of a library's functionality but have to import 100% of it. Etc...
But the problem - and I say this as someone who was like this for years, is when you reach for a library before attempting to actually understand the problem or what the library is doing. Then it's just Google driven development. And you better hope that the library has example code you can copy and paste and modify to fit what you're trying to do, because when you don't understand anything about what's going on under the hood that's mostly what you're going to do.
Like I said, I was like this for a long time. Libraries were a black box to me. I still work with people who are like this. In the article this comment thread is about, he talks about how he released an open source library for doing advertising on Windows Phones and got tons of Issues from other "developers" wanting new feature/changes.
Their mindset isn't "I could add this myself" or put in a pull request, this guy who I am relying on to do a part of my job for me -for free- needs to fix this.
Ultimately, you don't grow as a developer when you think like this. You don't grow to become the kind of developer that makes libraries. It also gets harder and harder to be effective the more senior you get. Because if you need a feature the package you're relying on doesn't have, you're SOL.
Good points thanks for clarification.
My general approach is to treat libraries as black boxes untill they I need more from them or they behave weirdly... Then I try to understand them.
I've been lucky that the area that I am working on has well documented and up to date libraries.
Working this way allows me to be faster than most of my coworkers who try to understand every piece to the fullest.
Working this way allows me to be faster than most of my coworkers who try to understand every piece to the fullest.
Depends on what your career goals are. If your goal is to just live a comfy enough life doing coding, sure. If your goal is to be making staff engineer salaries at FAANG, probably not.
Yes generally. However to evaluate how good a library is, do you not need to know what it is doing?
[deleted]
How did you learn these? I tried CTCI but I found it so mind numbingly dry and boring that I couldn’t read it for more than five minutes without falling asleep.
Go with "Grokking algorithms" and then with "Algorithms unlocked" to get some intuition. Then I recommend intro about alogirithms design from "Cracking the coding interview". Then i would read "Algorithm design manual". Then if you are interested add CLRS. After that MIT advanced courses and papers. Supplement with solving whole leetcode and you will be a beast.
Thanks for the recommendations.
It depends on where you're at. I'd recommend taking a course on data structures to brush up first. Then LC until you are doing Mediums. Then, it's just a matter of trying to figure things out and reading up on solutions. I dig in where I feel like I really don't understand a concept.
Isn't CTCI basically just a workbook? It has ~20 pages of intro and then problems and solutions. So it's not really a book you 'read' anyway, it's one you work through. I think the way you get really good at data structure/algorithms problems is by doing a lot of them and there's no way around that.
So grinding leetcode in other words?
"Luck Is What Happens When Preparation Meets Opportunity" - Seneca
IMHO, the key point here isn't so much about making the best out of a bad situation, it's that if you just stay cooped up in your comfort zone, the breadth of your preparedness isn't going to be nearly as wide as if you dabbled with things outside of your comfort zone.
You don't need to cram interview questions to get into big Bay Area tech companies: I did it without even knowing leetcode was a thing. But I gained similar preparation by working on an open source project. One of my best interviews involved a super in-depth discussion about some algorithm, and it went well because I just happened to have had implemented the thing in my OSS project and I knew from experience the trade-offs of different approaches in gory detail. Regardless, I never thought of that project as a drag. It was always a product of love.
Looking from another angle: Had I merely tried to make lemonades out of lemons, I'd certainly have mastered the technical skillsets that I used to use in my first job, but those skills turned out to not be the ones that carried me to where I am today. In fact, in hindsight, I had a lot of misconceptions about what preparation meant (e.g. I was too focused on specific technologies and too narrow-minded in some regards). The one thing that has served me well was the idea of broadening my horizons. You never know which seemingly useless obscurity is going to be a defining part of your journey.
IMHO, the key point here isn't so much about making the best out of a bad situation, it's that if you just stay cooped up in your comfort zone, the breadth of your preparedness isn't going to be nearly as wide as if you dabbled with things outside of your comfort zone.
You don't need to cram interview questions to get into big Bay Area tech companies: I did it without even knowing leetcode was a thing. But I gained similar preparation by working on an open source project. One of my best interviews involved a super in-depth discussion about some algorithm, and it went well because I just happened to have had implemented the thing in my OSS project and I knew from experience the trade-offs of different approaches in gory detail. Regardless, I never thought of that project as a drag. It was always a product of love.
Looking from another angle: Had I merely tried to make lemonades out of lemons, I'd certainly have mastered the technical skillsets that I used to use in my first job, but those skills turned out to not be the ones that carried me to where I am today. In fact, in hindsight, I had a lot of misconceptions about what preparation meant (e.g. I was too focused on specific technologies and too narrow-minded in some regards). The one thing that has served me well was the idea of broadening my horizons. You never know which seemingly useless obscurity is going to be a defining part of your journey.
The author is using "sunk cost" as if it were, strictly, a bad thing. Sunk costs are not fundamentally bad, they're a fact. Your education is a sunk cost, the money has been spent. Your car, your home, everything in your past are sunk costs. Sunk costs become problematic with a particular kind of reasoning: the sunk cost fallacy.
In that, you persist in an endeavor (job, relationship, project, whatever) because of the past investment (or primarily because of) even when all other signs indicate you should end it. "I've spent $100,000 on this money pit, I should keep going", only later to go into bankruptcy when the home could've been sold (perhaps for a loss) and a better quality one acquired.
What the author seems more interested in is the notion of "opportunity costs". Specifically, what can be done now instead of studying for interviews? Maybe you could do more OT and reap the rewards today of a higher income, at the cost of not qualifying for or getting jobs later due to a lack of preparation (jobs which might offer a higher base salary and obviate the need/desire for OT to supplement the income). Alternatively, studying now could (doesn't always, I've often studied on the job at least within reason) cost you pay because you aren't able to work some hours. Or it could cost you time with friends or partners or whatever.
The question is, is it worth the trade off and how long will it take to pay off if it is compared to the alternative activities and whatever they may or may not provide.
In that, you persist in an endeavor (job, relationship, project, whatever) because of the past investment (or primarily because of) even when all other signs indicate you should end it. "I've spent $100,000 on this money pit, I should keep going", only later to go into bankruptcy when the home could've been sold (perhaps for a loss) and a better quality one acquired.
What the author seems more interested in is the notion of "opportunity costs". Specifically, what can be done now instead of studying for interviews? Maybe you could do more OT and reap the rewards today of a higher income, at the cost of not qualifying for or getting jobs later due to a lack of preparation (jobs which might offer a higher base salary and obviate the need/desire for OT to supplement the income). Alternatively, studying now could (doesn't always, I've often studied on the job at least within reason) cost you pay because you aren't able to work some hours. Or it could cost you time with friends or partners or whatever.
The question is, is it worth the trade off and how long will it take to pay off if it is compared to the alternative activities and whatever they may or may not provide.
Also known as a "growth mindset". From what I've seen, I believe the majority of HN readers think this way - that most things are learning experiences, and that knowledge is power.
This article is interesting because I completely agree with the underlying point but completely disagree with the implementation.
The specific problems that occur in a programming interview were crafted because when the first developers were working on C code, that is what you needed to know to be able to make a program. As time has passed, our languages no longer have the same data structures and algorithm requirements, but we still ask the same questions because we have cargo-culted the interview.
And yet the author is entirely correct.
> "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." ― Linus Torvalds
Knowing data structures is incredibly important. It's just _different_ data structures. We need to stop learning backward looking algorithms and start learning forward looking algorithms and data structures.
Likewise, that same anti-sunk cost thinking is correct. John Carmack, for instance, is well known for having gone on "programming retreats"[0]. These are tasks that will not pay-off for his current project, but will allow him to change his thinking over time.
The next vacation I am going to go on I am going to attempt to learn microKanren, not because it has any value to my current work, and not because it has value to me getting a new job. I learn microKanren because I expect that I am going to learn something fundamental that the Torvalds quote above is hinting at. If data structures are so important, can we get to no code?
[0]: https://news.ycombinator.com/item?id=16518726
The specific problems that occur in a programming interview were crafted because when the first developers were working on C code, that is what you needed to know to be able to make a program. As time has passed, our languages no longer have the same data structures and algorithm requirements, but we still ask the same questions because we have cargo-culted the interview.
And yet the author is entirely correct.
> "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." ― Linus Torvalds
Knowing data structures is incredibly important. It's just _different_ data structures. We need to stop learning backward looking algorithms and start learning forward looking algorithms and data structures.
Likewise, that same anti-sunk cost thinking is correct. John Carmack, for instance, is well known for having gone on "programming retreats"[0]. These are tasks that will not pay-off for his current project, but will allow him to change his thinking over time.
The next vacation I am going to go on I am going to attempt to learn microKanren, not because it has any value to my current work, and not because it has value to me getting a new job. I learn microKanren because I expect that I am going to learn something fundamental that the Torvalds quote above is hinting at. If data structures are so important, can we get to no code?
[0]: https://news.ycombinator.com/item?id=16518726
I have an issue with the author calling it an 'investment' mindset. This is what consultants as part of their job. Taking their underlying assets (skills, network) and providing services to customers seeking these skillsets.
Calling it an investment mindset misses the actual point, that is most people when they talk about investment are mostly referring to things like - real estate, the stock market where they don't have to spend significant time doing that activity. One of the things I'm interested in knowing, is this something the author is doing full-time or is he does to support his other full-time activity? Some data about the revenue the author is making would be helpful.
Calling it an investment mindset misses the actual point, that is most people when they talk about investment are mostly referring to things like - real estate, the stock market where they don't have to spend significant time doing that activity. One of the things I'm interested in knowing, is this something the author is doing full-time or is he does to support his other full-time activity? Some data about the revenue the author is making would be helpful.
Despite the ease of development with modern languages and frameworks, the fundamentals still manage to creep in. Just the other day I was reviewing service code. Instead of letting the data store filter and sort the data with a single data call, the developer was pulling a larger data set and running an algorithm of nested for-loops to filter it in the service layer. I went straight to a Big O analysis of the code. Unfortunately, the developer had no idea what Big O notation was. AITA?
I find this largely to be true and a very useful mindset to have, however, personally I've observed two shortcomings:
1. At work, there are some projects that offer higher future value than others. Every task has some hidden future value - but some are higher than others. And predicting their value is, to me, better than random.
2. Eventually, you arrive at resume padding - which is a pretty demotivating and toxic mindset to have.
1. At work, there are some projects that offer higher future value than others. Every task has some hidden future value - but some are higher than others. And predicting their value is, to me, better than random.
2. Eventually, you arrive at resume padding - which is a pretty demotivating and toxic mindset to have.
"Again, you can’t connect the dots looking forward; you can only connect them looking backward. So you have to trust that the dots will somehow connect in your future. You have to trust in something — your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life." -Steve Jobs
Reframing coding and design challenges as an investment doesn’t mean that these challenges are not a sunk cost.
You missed his point. It's still worth doing those things as the process of doing them can result in other epiphanies that can lead you to greater opportunities down the line.
Eh... his point is largely making lemonade out of a situation of lemons. It's a healthy mindset for sure, but it's still forcing yourself to look on the bright side of a crummy situation.
Interviews test your ability to quickly solve silly problems under stress. This is a muscle you can get better at with training. And, yep, there's a non-zero chance that it make cause an epiphany or insight into something else. However, there's a much higher chance that it does not. Years into my career, my interest in grinding those type of problems just for the purpose of performing during an interview is effectively zero.
The thing that I love about CS is how broad it is. There's a great big world of things to dive very deeply into which aren't graph traversal algorithms or solving word problems. Being forced to halt your own personal research, hobbies, or interests because of our current broken interview system is lame even when spun as "I'll think of it as probably useful".
Interviews test your ability to quickly solve silly problems under stress. This is a muscle you can get better at with training. And, yep, there's a non-zero chance that it make cause an epiphany or insight into something else. However, there's a much higher chance that it does not. Years into my career, my interest in grinding those type of problems just for the purpose of performing during an interview is effectively zero.
The thing that I love about CS is how broad it is. There's a great big world of things to dive very deeply into which aren't graph traversal algorithms or solving word problems. Being forced to halt your own personal research, hobbies, or interests because of our current broken interview system is lame even when spun as "I'll think of it as probably useful".
Right, let me go to the moon because it'll make me a better golf player.
Makes sense.
Makes sense.
For those unaware, Wendy's (a hamburger chain in the USA) has a policy that cooked hamburgers need to be served within a few minutes of being prepared. This keeps the quality of the burgers up, however, it also causes a lot of waste since burgers need to be prepared ahead of time to really be "fast" food. So the founder of Wendy's decided to refrigerate the unused patties and use them the next day to make chili.
Chili wasn't a high margin item, it didn't make sense to make it from fresh hamburger. It was really a way for the company to offset the costs associated with serving hot, fresh burgers.
Finding a way to leverage code you've already built but wasted is a great idea. But that's not necessarily a great idea to go about intentionally wasting time in the hopes that you might recoup something back later. Keep focused on making high quality software first and foremost, but if you have some scraps left over from that focus, definitely find a way to make chili from it. Just don't get into the chili business.