> Excuse my ignorance, but aren't we glorifying speed here at HN? I think one project per month is way too fast to acheive anything of substance.
I think it's not about achieving anything of substance, it's about learning to code. Coding your own project from scratch is very hard and then effective for learning.
I really love to see that. I believe great programmers are the one who've started countless projects from scratch on their own (of course my opinion is oversimplified here). This, 1PPM, is really what you're looking for if you want to become a great programmer. Nothing else, just that. So go for it.
I agree with the author. You can't judge the passion of someone by his behaviour, that's silly. You can be as well a passionate programmer when you don't code home than when you do.
However, coding home has one - big - perk: it's almost the only way for you to code something from scratch. Alone. You and your code. You and your progress rate. You and your bugs. You and your choices. You and your mess. Nobody to smooth any angle.
I believe coding from scratch - alone - makes you a completely different kind of programmer indeed. But it has nothing to do with passion. Nothing at all.
I think (I can be wrong, still trying to validate that) that "number of projects from scratch" is the metric that tells the ultimate level of a programmer. In other words, if you've almost never coded anything from scratch (below say 40-50 projects), I do believe you are not very good at programming. Conversely, I know from experience (my own) that coding from scratch can make you so good, that you would find Amazon SDEs complete novices (I know from my own experience at amazon) and this before your 30's. It can make you better than principal engineers before your 30's. It can make you so good that TDD, OOP and agile development sounds like novice exercises to you. It can make you a programming master and beyond.
Could you be as good without coding from scratch really? Well, ultimately maybe but not as fast. Coding from scratch is so painful, so hard, so stressful, so frustrating that maintaining code or adding small to medium sized features is a baby step in comparison. Now of course, if you add something pretty big to an existing code base or make a god damn big refactor, you're doing the same thing as coding from scratch basically. The thing is that it's rare you 1) add that big a feature to an existing codebase 2) alone, in a big company.
I'm pretty sure the author has passion for programming, probably as big as anyone else. And balanced life is good for skills as feeling great makes you more creative amongst other thing. It's just that coding home makes you write a type of code that is 100 times more difficult than the one you do in big companies. Paradoxically, I'm pretty sure interviewers don't, at least consciously, know that.
Whenever I'm dealing with something that is serious to me, I always clearly first state to myself 1) what I want and 2) what do I do if I don't get what I want. For example in this case, it could be: 1) Jack told me this and that and I consider this is inappropriate. I never want to be told that again in this company 2) I leave.
What I do next is that I make sure I communicate clearly those two points to whoever I think should get me what I want. For example, in that case, I would go see my manager and say: "Jack told me this and that and I consider this is inappropriate. I never want to be told that again in this company. If it happens again, I quit. Have you understood? (wait for his answer) What will you do to make sure it doesn't happen anymore?" (it is important to ask if he has understood, it forces him to go right in the middle of the circle you just draw on the floor, that put him in your territory, right under your guns).
Sometimes, you will have to apply 2). For example in this case, your manager would have to tell you something substantial about what he gonna do to stop that. If what he tells you is not substantial, tell him you are not satisfied and ask him again the same question: "what can you do to make sure it will stop?". Don't quit on that. Keep asking. Only apply 2) if he don't answer anymore. It's typically a situation where "you don't leave the shop until...". If your manager tells you to go see the HR department, tell him clearly again 2): "if I don't get what I want I will leave. Do you still want me to go see the HR department? Are you sure?". Apply pressure, at every step.
Do not have a discussion. Don't discuss the problem with your manager. Don't talk. Ask your question and wait for an answer. If he want to discuss, make him understand you won't.
It's crucial to apply 2) right away when you don't get what you want. I've found it's rarely the occasion to make a deal and make a compromise not so much because the deal is bad but because by doing so, they will start kidding you again.
I'm super happy so far with the result of this method. I get fantastic results from my family, employers, friends, from everybody. At first, you will feel like a freak. Then you will notice the others won't think so much that you are a freak but will think you are a strong person they should not kid with. You end up being respected.
I have thought about that 10 more minutes and fortunately I get the same result as you: one can say of everything that "this is bullshit and the intention is bad". You dad got a new car? This is bullshit and the intention is bad. So my post achieve nothing good indeed.
So now, I have a question. I've noticed some people use a clever communication and social trick I call "word dropping". "word dropping" consists of forming sentences only in the intention to say or write a set of words because doing so can have an effect on some people. (Example of word set: de-risk, small market, big market, MVP, hire, key role, business plan, etc.) It is exactly like a text written with random words, it means absolutely nothing, but the trick is to do that with a limit set of words which when put together quasi-randomly provide a feeling of sense. One can see the disastrous consequences such a thing can have if people start believing into it. It's super powerful because word dropping cost nothing to produce and cost a lot to dismiss with proper arguments. This only hurts terribly.
I've found some people use plenty of social intelligence hacks like that, which works, hurts and decrease productivity. How do you protect someone from that? For example, say someone use word dropping to hurt me, what can I do? I guess I should read a book about that...
Just in case you got trapped, this is mostly a boilerplate which goal is not to help you but the author to get the appropriate image that would allow him to invest in companies that are doing well.
> How do competitors view you? Think about your 2-3 closest competitors. If you asked their CEOs to truthfully describe your company's strengths and vulnerabilities
Well, your 6 months old startup has no "strengths and vulnerabilities". It should also not have direct competitors. Only big companies have this kind of things. You have code, users and growth.
> Are you ready for a Series A?
> Imagine that instead of being the founder of your company, you're an investor
You already ask yourself these questions.
> The debate from hell
This one is decent and I'm nice. You already did this with your cofounder most of the time.
> Was your MVP truly minimal?
Who cares, you've survived.
> Stomach-churning churn numbers
You will stress automatically about churn.
> The missing key
Don't hire "key role". Only big companies do that.
> Laughed out of the room
Decent and I'm nice.
> Unexpectedly large market
By the way, only investors say market when talking about startups. While this has sense, it's kinda a concept for big companies again. Your startup has early users and say pool / niche of those.
> Unexpectedly small market
You rarely have an unexpectedly small market. Most of the time you have no market at all: you have built something people don't want.
> How does the trajectory of the world over the next 5-10 years align (or misalign) with what you're doing?
If you're growing, you're "aligned".
And on and on. The intention is not really to help you here I believe.
I think this is awesome and I encourage this extraordinaire effort.
Here are my reasons:
1. I've actually coded something similar a long time ago (I think Eve is even better than my solution) and it worked. My team and I were able to make entire apps in a heartbeat.
2. The reason it works is because, as pg famously wrote, programmers think in the language they use. Our cognitive load and power are function of the language we think in.
The key to Eve on this purpose is that you can program not only your app, but the development organisation that goes with it. Also, it is beginner friendly.
3. With 1. and 2., you get that Eve is related to reflectivity and homoiconicity. Maybe it is what's behind homoiconicity: your code and your organisation share the same language.
So I have a theory that may explains things here. Here it is.
There is 3 levels of programmers.
Level 1 is the beginner. A level 1 programmer is barely able to make a complete app or lib. His work simply rarely works. The code has no sense, is full of bugs, it's a complete mess, and the user has a very poor experience (if an experience at all).
Then comes the level 2 programmer. The novice. The novice learnt about OOP, design patterns, DRY, single responsability principle, importance of testing, etc. The only problem with the level 2 programmer is that he overdoes everything. He is victim of overengineering. He is able to make a complete app with a decent UX and the quality of the code is dramatically better, but his productivity is low. Really, really low. Everything takes month. Every single change is a project. 10 actual lines of codes need to be changed? That's 10 classes, 250 lines of unit tests, it requires 3 classes to be refactored, and on and on.
Finally, there is the level 3 programmer. The level 3 programmer is a programmer that does level 2 programming in a smarter way. His first principle is less code. That doesn't mean the code must be complete shit, but the level 3 engineer understand the real enemy and that all problems grow with it exponentially: code. The level 3 programmer knows, understand and apply the principles of the level 2 programmer, but he just does the right amount of them. Not too much.
If he has to, the level 3 programmer gonna err on the side of the level 1 code and will avoid as much as he can level 2 code. That's because level 1 code cost less to fix than level 2 code.
Now here comes my point: a level 2 programmer read and write articles that is about how to not be a level 1 programmer.
Personally I pick clojure by default. Clojure is a wonderful LISP that runs on the JVM which means there is all the libraries you need.
If I can't pick clojure, I gonna pick C because C works everywhere too and has all the libraries you need too. C is not functional but it is imperative and pretty damn simple.
I've been there, and this is a real concern. My cofounder and I both didn't succeed to get our experience really recognised and we both got to start again with entry level jobs. However, we've found that we got up in the ladder quickly. My cofounder is almost CTO again now after only 4-5 years.
> More interesting is to scan new submissions, download the article and run a model to predict whether it's interesting enough to upvote. You can start by scanning old articles and trying to predict votes.
While I see why you see that as interesting, I think that submissions should not be filtered by a computer based on content for quasi-ethic reasons.
Good post. I think too that reducing code is key. Here is how I like to show it.
Let's see what impact "size of code" has on "time it takes to add a feature". Just consider a graph where the X axis is "size of code" and the Y axis is "time it takes to add a feature". Obviously, the function is increasing, and probably faster than linearly.
Let's see what impact "size of code" has on "number of bugs". Same thing.
Let's see what impact "size of code" has on "time it takes to find a bug". Same thing.
Let's see what impact "size of code" has on "time it takes to resolve a bug". Same thing.
Let's see what impact "size of code" has on "time it takes to refactor a piece of code". Same thing.
Let's see what impact "size of code" has on "time it takes to a newcomer to be productive on that codebase". Same thing.
And on and on and on.
There is two canonical points on those functions. The first canonical point is when the codebase is too big for the value it brings. When you are here, you are in deep trouble. Basically, the cost of doing anything in that codebase is too high in comparison of the value it brings. A sign you are here is when you spend more time in meetings discussing what to do, than time coding.
The second canonical point is when the codebase is notably small for the value it brings. When you are here, the project looks like magical. The programmers look like 10x programmers. Indeed, doing anything on the codebase costs surprisingly little in comparison of the value it brings. A sign you are here is when you are not asked for estimations.
Aside some interesting comments here I find very true, my theory is that you should treat your game has a startup product: customers will not come, you have to chase them. And get them talk to their friends about your game. Just launching a game and making some marketing wont work. You need: feedback loop + word of mouth + growth.
I think it's not about achieving anything of substance, it's about learning to code. Coding your own project from scratch is very hard and then effective for learning.