This is good. I worked at google and lasted less than 2 years. Many other things happening in that time - came in via acquisition, worked on backend for that, dad died, transitioned teams, etc. But I was 27-28 and couldn't really navigate that world after my first job at a startup. In some ways, I wish I'd found a way, but in other ways, I know it wasn't meant to be. It's a good list, if you want to do 10 years at Google or elsewhere, internalise that list and it's lessons.
People read a lot of different things so I'm going to throw this one out there. I read the Quran. I read it continuously and it takes a while to finish but every time I read it I discover something new. People tend to discount a religious text as not for them but I think actually the translation or English narrative needs to fit the people and the times. Also the medium by which we read. I wrote an app to that effect to help me.
To anyone interested not just in reading it but asking it questions here's the app I wrote https://reminder.dev
I wrote https://go-micro.dev - A go framework for microservices. I've written a few other things in my time (https://github.com/asim) and tried my hand at hosted paid APIs which was moderately successful but failed as a VC funded business. I think I've just existed so much in an era of free consumer services like Google and open source software that it's skewed my perspective a lot. Like why charge for this, it could be free..m
So you walked out of the free carpentry store holding Linux, a Go compiler, Git, etc. and now you're looking to build stuff to sell to other carpenters! Non-carpenters don't need microservice frameworks or app platforms. Plus carpenters know they can usually get the stuff for free anyway - they were just in the same store as you!
Have a think about the relative sizes of the carpenter market vs. the non-carpenter market.
0.5% of humans are devs, but 70% of humans have internet. 70-90% of internet users have made an online purchase. (I assume these AI slop answers are at least in the ballpark)
(Anyway I really don't have a head for business, so don't take my advice. I just like programming on and off the clock and I get a salary for it)
No thank you for that example at least because I feel like I got hit in the face with a big fish. Of course trying to sell to other carpenters is mistake! Unless it's really refined tools they need, not the stuff you built with them. I guess the framework was a tool Devs need but I could never sell it...
Now carpenters selling to regular people. Ok finally my brain clicks. Take the easy route. Sell to people who don't code and help them win. Then it's about specialisation I guess. You could build anything, maybe there's a focus area. I did build https://mu.xyz but yet to figure out that user demographic.
I never heard the term mini framework before but I like it. Applied within that context it makes sense. I was at Google 2011-2013 through an acquisition and witnessed some of what the author is describing. Actually something very specific comes to mind. There was a SQL library built on top of BigTable, Google's internal columnar data store, I think it was called Megastore [1]. The team implementing a new product decided to use it over BigTable directly because what it would mean for ease of development but it turned out as soon as they needed to do any data migration it was locking the entire database (or I guess the table? Aka BigTable). Anyway at the time this was a major issue and they had to revert to BigTable best practices as opposed to what this library was doing. Because essentially it was a library layer, not some new data store. Eventually Google built a different SQL based data store to replace the whole thing which you can see the open source version known as CockroachDB, which some ex-googlers invented.
Moral of the story, abstractions always fail the edge cases, especially at scale. But when the entire eng org adopts something, it works much better. Everyone has to be bought in. Which at Google scale is hard.
Teach me oh Obi Wan. lol. I never made my bootstrapped efforts work. Neither did my VC funded efforts. Now with the next attempt, I think there's a lot of clarity in what bootstrapping gets you versus VC funding. Also solo vs team. Timelines are so different, the approach is so different. I don't think there is the same urgency in bootstrapping. You can have longer time horizons. With funding its a go-go-go attitude, especially with that finite funding. But even when it goes right and you became public, you are at the mercy of a quarterly report where you have to show something to keep that stock price propped up. I'm sure people running the company will say it doesn't make them think differently but the long termism breaks down a little unless you are pumping cash from somewhere.
Anyway, if I had my shot again, I'm not saying I'd renounce funding. Bootstrapping for a short period to figure things out is great, but funding also creates opportunities where an immediate business model is not clear. Opportunities exist for different approaches. Again not an advocate for the VC funding, but I'd taken even $500k these days to get something up and running as the cost of capital is basically nothing aka YC.
> Anyway, if I had my shot again, I'm not saying I'd renounce funding. Bootstrapping for a short period to figure things out is great, but funding also creates opportunities where an immediate business model is not clear. Opportunities exist for different approaches.
Absolutely! There are some problems that can only be tackled with some serious funding. There are people who enjoy the go-go-go attitude of VC-based startups so much. I'm not against VC funding per se. It's just important to recognize that it's not the only path and that there's nothing wrong if that route isn't for you, for any reason. You can be successful in other ways.
I don't do any of that. I find with GitHub copilot and Claude sonnet 4.5 if I'm clear enough about the what and where it'll sort things out pretty well, and then there's only reiteration of code styling or reuse of functionality. At that point it has enough context to keep going. The only time I might clear that whole thing is if I'm working on an entirely new feature where the context is too large and it gets stuck in summarising the history. Otherwise it's good. But this in codespaces. I find the Tasks feature much harder. Almost a write-off when trying to do something big. Twice I've had it go off on some strange tangent and build the most absurd thing. You really need to keep your eyes on it.
Yeah I found that for daily work, current models like Sonnet/Opus 4.5, Gemini 3.0 Pro (and even Flash) work really well without planning as long as I divide and conquer larger tasks into smaller ones. Just like I would do if I was programming myself.
For planning large tasks like "setup playwright tests in this project with some demo tests" I spend some time chatting with Gemini 3 or Opus 4.5 to figure out the most idiomatic easy-wins and possible pitfalls. Like: separate database for playwright tests. Separate users in playwright tests. Skipping login flow for most tests. And so on.
I suspect that devs who use a formal-plan-first approach tend to tackle larger tasks and even vibe code large features at a time.
I’ve had some luck with giving the LLM an overview of what I want the final version to do, but then asking it to perform smaller chunks. This is how I’d approach it myself — I know where I’m trying to go, and will implement smaller chunks at a time. I’ll also sometimes ask it to skip certain functionality - leaving a placeholder and saying we’ll get back to it later.
Same. I find that if I can piecemeal explain the desired functionality and work as I would pairing with another engineer that it’s totally possible to go from “make me a simple wheel with spokes” to “okay now let’s add a better frame and brakes” with relatively little planning, other than what I’d already do when researching the codebase to implement a new feature
It's quite interesting because it makes me wonder how we make it efficient and predictable. The human language is just too verbose. There must be some DSL, some more refined way to get to the output we need. I don't know whether it means you actually just need to provide examples or something else. But you know code is very binary, do this do that. LLMs are really just too verbose even in this format right now. That higher layer really needs a language. I mean I get it. It's understanding human language and converting it to code. Very clever. But I think we can do better.
Based on the responses it's a lot of people who manage their own email domain or servers. Not the norm. I think most people would not have aliases and things like this but would probably benefit from it.
Agree with Go being basically C with string support and garbage collection. Which makes it a good language. I think rust feels more like a c++ replacement. Especially syntactically. But each person will say something different. If people can create new languages and there's a need then they will. Not to say it's a good or bad thing but eventually it would be good to level up properly. Maybe AI does that.
reply