Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
I like it! Although 3 and 4 are contradictory.
If you convince yourself that you're core ideas are right from the start, how will you be able to listen to criticism without being butthurt? Even after agreeing that your ideas are stupid, you'll still be reluctant in changing them if you followed rule 4.
It's better to start knowing that it's certainly not perfect until proven otherwise, because let's face it, it's not very likely that you'll have an awesome idea right from the beginning. But it's okey, cause now you're in the right mindset and can handle criticism. But you still need to believe in yourself to weed out non-constructive remarks and focus on the helpful ones.
Anyway, that was a wordy answer but I hope you get what I mean.
Great stuff man! Imma start following in when I stop crying about being a huge procrastinator :DDDD -
This is just extremely well laid out, cold and straight.
The users don't give a shit about your code quality. They don't even care if you have a backend or not. They care that what you did is fun/interesting/useful. Hopefully all those at the same time. That's far more important to them than anything else.
It should be to you too or otherwise you'll never hit the milestone where you can actually afford start hiring all those expensive engineers who only care about code quality.
I see very good developers here joining startups that do something as lame as Facebook advertising. Or some weird food delivery thing. That's because in the end the developers just need a good opportunity to write beautiful code. The business case hardly matters to them, the tools, colleagues and tech weight far more. And salary.
Build for the users. All the rest comes later. -
@Shisuki "I like it! Although 3 and 4 are contradictory."
Not really. I just didn't express myself well.
Plan with criticism in mind, but once you're committed, stop second guessing every move. -
@AndSoWeCode @Shisuki I agree. Not contradictory.
You chose to listen to your peers too, you deserve that people talk. -
It's good, but I disagree with part 2.
We actually use Clojurescript, despite that there's a very few to none developers available to hire.
But, with its high performance (persistent out of the box), awesome lispy data processing features and awesome re-frame we were able to ship the prototype in about two months.
Yes, clojure has its learning curve for newbies. But when I try to imagine the bloody hell we'll be into if we decided to use react (add redux, react-router, redux saga, redux thunk, reselect, immutablejs), it makes my eye twitch.
We actually ended up hiring js developers and teaching them clojure. They were happy. Because
"Clojure attracts smart people."
— Rich Hickey -
@uyouthe nim is more readable, yet again nobody uses it.
Put it like this: if you list Clojure in your job requirements, few will ever join and you lose. If you don't, then people who never heard of ClojureScript will join, and instead of starting to work productively within 1-2 weeks, it's gonna be a month or two, or more. And then it's vacation time. And then job satisfaction falls because nothing is being done and people feel stupid. And then they just switch jobs, and nothing ever gets done.
The scenario of that happening is much higher than on other languages. This leads to big projects becoming unmaintainable.
If I had a dime for every time I have seen a company hired unprecedented effort just to scrap some weird program written in a weird language, and rebuild the exact same one using a mainstream language, just because it's maintainable, then I'd get myself an excellent ice cream. -
@AndSoWeCode Clojure is not "weird". Weird is when there is something that's there "just because". Et tu, js?
Clojure is modern Lisp. Compared to Lisp, JS is "weird". That's hard to disapprove.
By writing web apps in React + Redux, the most popular stack over there, you obviously doing functional programming. And the clojurescript is just more efficient and straightforward way of doing so, and Lisp has been around for 50 years.
If you know how to do fp, you already know Clojure. I was able to get up and running in two days, so as our other ex-js devs. Thanks to amazing docs, amazing Leiningen (forget about webpack nightmare, everything works out of the box) and amazing community.
And if you don't understand fp, you can't even do react+redux. That's it. -
@AndSoWeCode but you're right, weird languages or stacks often doom projects down to unmaintainability and makes teams lose time and money reimplementing them from scratch.
mkdir new_project
cd new_project
git init
**Reflecting on my life and current workload**
cd ..
rm -rf new...
KISS.
Keep it simple, stupid.
At the beginning the project is nothing but an idea. If you get it off the ground, that's already a huge success. Rich features and code quality should be the last of your worries in this case.
Throw out any secondary functionality out the window from day 0. Make it work, then add flowers and shit (note to self: need to make way for flowers and shit).
Nevertheless code quality is an important factor, if you can afford it. The top important things I outline in any new non-trivial project:
1. Spend 1-2 days bootstrapping it for best fit to the task, and well designed security, mocking, testing and extensibility.
2. Choose a stack that you'll most likely find good cheap devs for, in that region where you'll look in, but also a stack that will allow you to spend most of your time writing software rather than learning to code in it.
3. Talk to peers. Listen when they tell that your idea is stupid. Listen to why it's stupid, re-assess, because it most probably is stupid in this case.
4. Give yourself a good pep talk every morning, convincing you that the choices you've made starting this project are the right ones and that they'll bring you to success. Because if you started such a project already, the most efficient way to kill it is to doubt your core decisions.
Once it's working badly and with a ton of bugs, you've already succeeded in actually making it work, and then you can tackle the bugs and improvements.
Some dev is going to hate you for creating something horrific, but that horrific thing will work, and it's what will give another developer a maintenance job. Which is FAR, far more than most would get by focusing on quality and features from day 0.
undefined
wk70