This was an amazing read, and frankly inspiring with regard to your final thoughts. I’ve yet to build anything substantial on the side but still searching for that idea
now I’m convinced that a certain senior engineer at a very well known tech company had this as an instruction manual. I’ve experienced each of these multiple times from the same person!
On my own though, I’m certainly guilty of the 100 round trips. I tend to mentally group nits and not spell out every one that I find
You: Have problems related to data, want to modernize your operations (no more clickops), want to build a mobile app, want to add AI to your product.
Me: 10 years of experience, previously at Amazon, currently an LLM research engineer. Expert in CI/CD and Infrastructure as Code through Terraform. Skilled in building AI-enabled application through the usage of RAG and agent-based workflows. Also have built many MVP style products with Flutter and .NET.
I can handle your Sagemaker MLOps, can help experiment with LLMs, and can build products with Flutter, or Ruby on Rails. Fullstack. I've helped one startup reach exit by building fitness tracker integration into their flutter app (https://fytfeed.com). I've tried to build several products myself with C#/.NET, Flutter, and Django
It may be time to finally learn it. I've standardized on Python, Clojure and C# of all languages (Julia for fun) but Rust may help me dive deeper into systems level problems.
You're right. I think my biggest problem is that I always assume these crazy OSS projects were written because the author has always been this programming genius, when in reality they were just following their interests. For example, I caught myself with the proxy thinking about production scale. Who cares about production?? I just need to get going and build a single-threaded proxy that gets the job done. No need to worry about complexity, it's just for me.
I loved this article, this is exactly what programmers in my community complain most about with regard to lisp.
The greatest strengths for me are the scoping and how lisp enables interactive development. For one, I don't even see parens anymore when writing code. They've become automatic where I'm able to parse structure at least better than I have in the past. With a REPL, (I specifically use Clojure), development has become fun again. A typical debugging process is attaching to my actual program, and calling functions seeing what happens.
I love the flow of defining functions in my code, `def`-ing some test data, and calling those functions. I'll use `cider-inspect` to see if the data structure looks correct and iterate.
Everyone should at least try a lisp. Iterative, interactive development is so fun and powerful.
I'm wrestling with this same question myself. I have never had any idea. For me I've started businesses when the external pressure of having a co-founder dictated that I should. Or, I'd be in a fit of passion-inspired development for a few weeks until it was time to talk to customers. I think the answer varies from person to person. It's hard to say what a good heuristic would be. We all operate with different heuristics.
For instance I now have a family, and starting a business would either take me away from family time, involve nights and weekends work, or involve quitting my day job (of which the bar is now very high).
I actually created a set of heuristics that would increase the likelihood of success for the company. However, I am occasionally frustrated by the amount of time it takes to prepare for these conditions before actually founding the company. Maybe it helps.
1. Maximize the effect of geographic arbitrage.
Regarding the macroeconomic, political, and social situations of countries regarding their GDP, GDP per capita, and the number of millionaires and billionaires gives a good idea. There are also chances that highly skilled people are also there.
Solution: Immigrate to the country and best city in this manner.
2. Maximize legal flexibility.
- Having citizenship in a country is hugely advantageous in terms of safety net, a good passport for global travel, and making business with specific industries.
3. Have a skill set and job that make you the top 5–10 percent of earners. Wait to see where salary increases change marginally.
When you start working, climbing to a high-paying job and being in the top 5–10 percent of earners in a population is significantly easier and safer than building a business. However, after some years of year-to-year increases, the salary doesn't move you in lower percentages significantly.
4. Acquisition of enough information regarding operating business.
- Having knowledge regarding the meta-information of business like legal, accounting, HR, marketing, logistics, manufacturing, etc.
5. Global Industry Wave
Riding a historical wave of technologically induced progress can increase the potential maximum of the point significantly.
6. While having the job first, MVP builds, ships, and sales have been done.
7. Having 200–250k of money to burn.
With three founders each putting similar money this is enough money to build a team of 3–4 people and keep the company alive for 12–15 months.
But as I said, these things in my own abilities take years and years, and it is really frustrating. However, I know it is logical or a good plan. I would love any feedback anyone have.
I've had a lot of trouble with hiring lately due to being a generalist. I've spent 10 years as a developer but not more than 2-3 at a time in a specific "stack." This has hurt me more times than I can remember.
However, I've built amazing things for amazing companies when I do get jobs. I've architected and built end-to-end products by myself and within teams. A few projects I've worked on: a web scraping product, data labeling software for machine learning, commercial eyetracking software, a custom learning management system, machine learning models from scratch, high volume image processing, etc. In each of these projects too I did end-to-end work. Development, deployment, infrastructure, ops.
Each one of these products though was with a different stack. JS, C#, Clojure, C++, Java, Python, the list goes on.
Common feedback I've received is that I'm not experienced enough to deliver in a role. Anecdotally, engineers that I talk to where I'm located have spent their entire careers using only JS, building Next.js sites or whatever the current hotness is. Not that there's anything wrong with that, but it does seem like the landscape has shifted to the specialists.
I don't have trouble, but companies are very leery of hiring someone who is VERY wide and only somewhat deep. Being I'm a director-level hire, many companies assume I have only led teams that do this work and I'm trying to take credit for their depth in specialized areas, not realizing that I absolutely can and do operate across that wide swath of expertise.
I try to use the successes I have cultivated at multiple organizations in the past with this experience as evidence, but even after hire, most organizations take ~6 months to realize I'm not too good to be true; it's part of why I end up getting promoted a few times in relatively rapid succession at each gig.
I find that working at smaller companies (~125), they idealize those who can wear many hats, whereas companies that are large enterprises do not and are much less likely to hire someone who can do it all, favoring--instead--those who are very deep and narrow. I have carved out a successful niche in the digital marketing space with the experience and success I've had and I will likely continue to do so, helping those same large enterprises who would likely pass me over for a FTE role, but happy to hire me via a consulting firm to solve the very same problems while paying much more for the pleasure.
Valuable advice. I've found the same w.r.t. working at a small company versus an enterprise. I think I'm in the niche carving stage of my career but I have no idea how to sell myself. I'm in the same boat, I can and do operate across that wide swathe of experience as well.
It's been feeling lately like I'm at a crossroads, I either settle down and "specialize" by picking a stack and an "area," or I build my own product.
I think the sales pitch of the generalist is that they can draw from multiple disciplines to bring in new ideas, or make connections, that the specialist can’t do. The generalist can more easily see the big picture, because they have experience in all the parts that makeup that picture. That means fewer blind spots and unforeseen issues late in the game.
It's all a tradeoff as there are only so many hours in the day.
I was an IT industry analyst for about a decade and basically brought that background to an internal vendor role.
On the one hand, the company I was with valued a broader perspective. On the other hand, get too broad and you risk getting into shallower trade press takes where some writers have heard various terms and memes but don't have any real deeper understanding of most things.
So it ends up being about developing legitimate expertise on certain related topics while having some conversational familiarity with others--and maybe just admitting you don't have more than a very surface understanding of still others.
We have a lot to do „thanks to” all the guys that are BSing.
I myself also consider generalist with quite a lot of success ranging from improving code performance in .NET and MS SQL to setting up whole servers with AD and best practices to technical hiring.
But I saw maybe one other or 2 really like that.
Other 20 or something „technical generalists” were business people hustling to be managers trying to look technical or outright scammers trying to loook like they can do everything but then delivering nothing.
It usually takes around 6 months to uncover the guy that is BS then another 6 months to convince manager guy knows shit and we have to fire him asap.
You nailed it my sentiments exactly. And funny, I keep thinking that I'll land in marketing at some point myself. They don't want to admit it, but your average "digital marketer" with no formal education in math or statistics really has no business trying to understand their audience.
