My “Investment Mindset”
blog.pragmaticengineer.com
blog.pragmaticengineer.com
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.
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.
At least that is my approach to programming.
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.
Working this way allows me to be faster than most of my coworkers who try to understand every piece to the fullest.
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.
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.
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?
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.
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.
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".
Makes sense.