> 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...don't know about that. I've worked with several programmers who were great at getting something up and running, but we're kind of crap at going deeper--adding depth, maintaining. I'd go as far as to say they typically had an attitude of "I got it up and running, mission accomplished!" Maybe they need to get closer to that 1000 mark to learn the value of planning for the long term, making something you can continue to build on, etc.
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.
there another side to it. coding alone making all decisions on the fly and as needed can also be very relaxing. in the big company, most of the work is getting agreement; fighting legacy code; planning transitions; making sure everybody is on the same page as they contribute...
Exactly. I have seen people who are fantastic developers when working on solo projects but start to struggle when placed in a business/group environment. Once things like business priorities start informing what people are going to be working on when, once folks need to start coordinating with other developers and their own quirks it starts going downhill
This, a thousand times. I'm an excellent bug-fixer/chaos-manager/refactorer and this led me to believe I should be an excellent project-starter as well. It has bit me in the ass more times than I can count (although I'm getting better with each new project).
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.
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.
This sort of dismissal based on platitudes ("Most of the time you have no market at all") is the sort of comment we don't want on Hacker News. Anything can be dismissed this way, and anyone can do it. It feels good, gets upvotes, and generates more of the same—and thus the discourse clogs up up with more and more of this. That's bad. And what does your apparent critique boil down to? "The intention is not really to help you here I believe"—in other words, (a) you read minds and (b) you assume your conclusion.
For higher-quality discussion, we should apply the Principle of Charity: that is, assume the strongest plausible interpretation of an article and respond to that. Poking holes in a weak one may be fun but it is not substantive.
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...
It sounds good, but isn't good. I think the answer in response to it is to have ammo that both sounds good and is useful, and it'll win out to the smart people.
Sadly, the upvote system reacts eagerly to many things that are bad for HN, e.g. indignation, snark, cynicism, sensationalism.
One can speculate about why—my theory is that it plugs into reflexive neural circuits, rather than the slower, reflective ones that make for more thoughtful reactions—but the fact itself is painfully well-established.
Really interesting counterposition of the terms "reflex" and "reflect". Both share the same etymological root and core meaning, but through application have mirrored distinctions that make them perfectly beautiful opposites, in the way you're using them.
It's common for etymological roots to branch to opposites, or simply invert. And then maybe revert again. Almost too common to note, really. A byproduct of how core association is to our minds it would seem.
You theory lends itself to validation. One aspect is timing - upvotes produced later after reading will be more thoughtful. The other aspect is effort - if upvote required certain effort over a length of time, that upvote too would be more meaningful. On the other hand, a short burst of heroic effort points to a reflexive reaction. If we could somehow inject effort into the voting we would get some really meaningful weights for each vote. This could be calibrated with manual review of sample comments. We could also use this knowledge to calm people down - confronting a person with a lengthy task might give them time to rethink their position.
So... how is that for an idea: having voted on something you get an option to return and double-down your vote, but no sooner than five minutes later. To try more things we could also show the user his recent upvotes, and mix in some comments he did not vote on, so that the user had to stop and think.
I think you're dismissing the competitors too early. It can be viewed more broadly as well.
You are not just competing with similar businesses, but also the potential that customers literally 'do nothing'.
In addition to that, there could also be legacy solutions or alternative ways of avoiding the issue that your company seeks to solve.
Another important spin on this might be if you /should/ have had competition but they no longer exist. That's something that the search here can turn up and provide further input for the other thought points.
A great way to look like an idiot is to get up in front of VCs and say there's no competition. The points that you bring up are all much better things to talk about than a flat "we have no competition" claim.
Supply-demand dynamics at play. The general answer is no, though. Chances are higher if you use these in your own domain and become an applied expert or if you win some competition on Kaggle or similar tough envinronment.
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.
> 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.
I've been doing this recently and had a hard time justifying it even to myself. It just felt right. And you've got it - it's easier to fix dumb code, than refactor an overengineered mess.
> Now here comes my point: a level 2 programmer read and write articles that is about how to not be a level 1 programmer.
You're making me understand the current programming "scene" much better, especially the plethora of self-aggrandizing blog posts I tend to see today.
I disagree that level 1 programmers necessarily produce poor code. But they're stuck at such a low level of understanding of abstractions that they either abuse abstractions to hell (but not in a level 2 sense) or don't use them at all.
The good level 3 programmer understands that there are times to call a function, times to create class hierarchies, times to create generators, times to use high level abstractions. But they generally err on the side of lower abstractions, or higher abstractions only where they aid clarity, reduces true redundancy, or similar.
But the most important thing about a level 3 programmer is that they aren't dogmatic. Dogma both frees and constrains the developer. It frees them from the requirement to think, because dogma says "thou shalt" and "thou shalt not". It constrains them because when things fall outside the dogma, they want to make the heretical code conform, or they discard it and start over.
That depends on circumstances really. Yeah it's easy to fix dumb code... unless there's 10 tons of it
I once worked with about 1.5 million LOC worth of "naive" PHP code. It was one big e-commerce system. The SSOT principle wasn't followed, certain assumptions were scattered all over the place.
For example the fact that a product could only ever belong to a single size group. The task we were given was to remove this constraint. It took a few man-years of work, because it was hardcoded EVERYWHERE, from database scripts to frontend JS. And don't even get me started on how many bugs angry customers encountered before it got kind of stable.
It wasn't overengineered, just dumb, and a lot of it. I'd much prefer having to deal with some matryoshka OOP abstractions - they could be merged, simplified etc. In such case there are certain tricks in our disposal. Tricks that scale. If it's just a big ball of mud: not much you can do. It's pretty much a physical job, like counting grains of sand on the beach.
When you design a system, you always have a tradeoff between flexibility and simplicity. Extreme flexibility means over-engineering and complexity. Simplicity means less flexibility, because of a lot assumptions are hard-coded. The best design is the one which hits the sweet spot: As simple as possible, as flexible as necessary. That requires knowing the future, though.
If you want to increase flexibility later, like "remove the constraint that a product could only ever belong to a single size group", it inherently means to hunt down all the places where this assumption has been hard-coded.
Should you err on the side of flexibility or simplicity? Simplicity means the assumption hunt is costly, but maybe you never need it (YAGNI). Err for flexibility, you pay the constant cost of dealing with the API complexity, but you surely avoid some costly assumption hunts.
Usually, startup prefer simplicity because they will pivot anyways. In contrast, enterprise prefers flexibility, so they can plan years ahead and things stay in the budget.
> As simple as possible, as flexible as necessary. That requires knowing the future.
Knowing the future in this case should usually mean that you have requests for a feature from customers, but you don't have time to do it in this version. At least that is something I find useful as a rule of thumb. If that is not the case, you should really think twice before making it flexible rather than simple.
I was recently passed off a project from someone who didn't have a development background but had been working on C++... the amount of copy-paste, repetitive if statements and fixed length arrays makes the original code almost completely unusable and I was forced to suggest a total rewrite.
> If it's just a big ball of mud: not much you can do. It's pretty much a physical job, like counting grains of sand on the beach.
You can refactor as you go. It doesn't save you from sifting through the entire ball of mud, but at least it means you won't have to do it again in quite such a bad way.
Same here. I started applying LEAN lately and I'm more productive than ever. I just stopped creating interfaces and as-atomic-as-possible components in favor of simple but sometimes dumb classes which do the heavy lifting and can be easily replaced by more robust code when it is needed.
There's another dimension that I think you're missing, which is having sensible levels of abstraction.
A good, easy to understand codebase is one that has a minimal number of components that interact with each other in a well-organized and easty-to-understand manner. Those components, in turn, should each be made of a minimal number of sub-components that interact with each other in a clear, well-organized manner. And on down until you hit bedrock. Doing this is essential because it sets up boundaries that limit the amount of code and interactions that you need to juggle in your head at any one moment.
A programmer who doesn't understand this will produce horrible, tangled, tightly-coupled code regardless of whether they're doing it with a boiling soup of global variables or a boiling soup composed together from tiny "well-factored" classes that all implement interfaces containing only a single CQRS-compliant method.
I'd submit that there's another level of programmer, let's call it the SubGenius programmer (because the term tickles me) who thinks that levels 1, 2 and 3 programmers all share a sloppy work ethos and need to spend more time stepping back to keep an eye on how the forest looks instead of obsessing about trees all the time.
I have to confess that I am probably a level 2 programmer, and the only thing that stops me is pair programming and code reviews. I always start out with good intentions, but the little "what if?" devil on my shoulder whispers things like "What if you need to change that dependency?" and off I go creating an AbstractFactoryFactoryManagerServiceInterface. At the time, his comments just sound so sensible and wise. The only way for me to snap out of it is when the "good programming fairy" is on my other shoulder (probably my colleague) saying "Do you really think that's necessary?"
Finding the right balance between those is the Art of Design.
Since ageism is a hot topic now: This is one point where experience pays off. The graybeard has acquired a better gut feeling when something is necessary and when it is not.
This is why I frequently ask up the chain to confirm requirements in a "is it ever possible we might want to do X?" way quite often. Getting outright "no"s will often help to simplify your design and if it comes back to bite you in the ass, you just tell them you asked and will now need additional time to redesign and refactor.
Please consider replacing all the "he"s with a word less gender-defining ("they", "s/he", "ve" etc). The entire gender spectrum can code if they want to and they should feel included rather than excluded.
> Please consider replacing all the "he"s with a word less gender-defining ("they", "s/he", "ve" etc). The entire gender spectrum can code if they want to and they should feel included rather than excluded.
The vast majority of programmers are male, so (ignoring that he can be used in a gender neutral way) it's natural to use he in such a situation. I'm not saying it's right or wrong -- I'm not sure what influence using gender-specific pronouns has. Although I will say that if someone used she when discussing a field that is dominated by women, like veterinary science, as a man I wouldn't feel excluded or put off from exploring the field if I had an interest in it. It's also interesting to note that the same furor over gender inequality in subjects like computer science isn't replicated when the shoe is on the other foot.
I think there is a tendency in western culture at the moment to confuse factual differences in behaviour between men and women with ethical issues about equal opportunity. Equal opportunity doesn't necessarily result in a 50/50 gender split in all fields. Christina H. Sommers puts it better than I can: https://www.youtube.com/watch?v=l-6usiN4uoA
Please please please, for the love of programming, let's not turn this into another one of _those_ conversations. Use it, don't use it, just don't start flame wars.
Your hypothetical doesn't apply. There's no way for you to know the subconscious impact in the long term that everything being referred with "she" would have on your interest in Veterinary work, if you did have one. It's not something you can mentally put yourself in, and know for sure it would not bother you.
Also, I think this was kind of apropos. Seems like the English language isn't using the right levels of abstractions. There should be a true gender neutral pronoun, one that should be used when the gender specificity isn't relevant and should be hidden away behind the pronoun's abstraction. Its just not something we're familiar with, and that's really the only problem. Its hard to force language on people, when everyone learns language effortlessly as they grow up, nobody is used to putting effort in how they talk.
> Its just not something we're familiar with, and that's really the only problem. Its hard to force language on people, when everyone learns language effortlessly as they grow up, nobody is used to putting effort in how they talk.
These sorts of situations are a direct result of the battle "to force language on people", and they are having a big effect on our society. Sethi paid a high cost for a single tweet that wasn't intended to be malicious in any way. And people who read such stories note this, and as a result feel like they must tread on eggshells, because, even though they aren't racist or sexist or any other ist, one small slip up may result in their entire education or career being put at risk.
A populous that is scared to say anything is much easier to control. And I think the powerful are going to get what they want with this. In a couple of decades, I think free speech will be a distant memory, and people like yourself will be questioning the future you helped bring about.
This is just silly. Besides, grammatically, "he" is a gender neutral pronoun when referring to a person of unspecified gender (as in other languages). "They" is plural. "Ve" is not a word. "S/he" is awkward and unnecessary (and hey, we can argue that it is misandrous because you're capitalizing the "S" and prioritizing "She" over "he"; if you argue that it doesn't matter, then the same can be said about "he").
> Besides, grammatically, "he" is a gender neutral pronoun when referring to a person of unspecified gender (as in other languages).
No, grammatically, "he" always has masculine gender [0]; its historically-accepted (though increasingly-less-so) semantics include use in reference to a person of unspecified (socially-ascribed) gender (classically, use of personal programs in English maps best to socially-ascribed gender, which has not taken gender identity much into account -- recently, there's been a move to align socially-ascribed gender with gender identity, but pronoun use basically follows the former which just happens to have a growing norm of also aligning with the latter.)
> "They" is plural
"They" is grammatically plural and gender-neutral, but has a very long history of accepted use with semantics of referring to an individual of unspecified (socially-ascribed) gender. This acceptance was somewhat reduced by the Victorian fad of Latin-inspired prescriptivism in English, but this reductions is among those of that fads effects that have been fading over recent decades.
[0] Note that grammatic gender is a distinct concept from either socially ascribed gender of a person, gender identity of a person, or biological sex of a person.
Given an HN reader took the trouble to email me their thanks for my comment, I respectfully disagree. To do this, they had find my email address by following some of my other comments, linking to a website, following through to github... The email they wrote was articulate. They put in real effort to say "thanks".
> "he" is a gender neutral pronoun when referring to a person of unspecified gender (as in other languages).
In some dictionaries, yes. A possible counter-argument to this is that the tradition of that usage comes from cultures with significant inbuilt misogyny.
Agreed. I dislike this form. A similar option is to alternate use of "he" and "she". This form is common, and probably the simplest. I wish I'd suggested it.
> we can argue that it is misandrous because you're capitalizing the "S" and prioritizing "She" over "he"
And the idea that "he" is gender neutral always seemed to me like a post-rationalisation for people's androcentrism than any kind of well founded rule.
Singular they or s/he would be fine, but personally I've never heard of "ve", which I had to look up and doesn't even appear on the first page of google.
Dude is unisex these days, and i think the original claim is also ignoring non-binary people who conform neither to male or female gender stereotypes (wrt wanting more women in tech). we should also want to increase visibility of non binary people
If such a small thing is enough to discourage women from entering the field, then by all means it should be done at this stage rather than after several years of college or in a workplace.
I hate to pile on the downvote-fest here but I don't understand how some people have come to a place where they believe the world would be a better place if used the correct pronouns. Good intentions, I'm sure, and your comment wasn't rude, but seriously stop telling people how to live their lives.
I fail to see how contributing to a downvote is "hating to pile on the downvote-fest".
To defend my point a little: I invited them to consider their use of language, not tell them how to live their life.
I can tell you how I came to this view: I read around through philosophy, pop-psychology/self-help, nlp, linguistics, religion and science-fiction; I spoke with feminists; I spoke with trans-folk and their admirers; I looked at my assumptions as a younger person and found them wrong.
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 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.