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
Search - "wk375"
-
Reject original specs. Do the bare minimum MVP that works and solves problems people actually have, and not problems you think people have.
Improve it if needed.
In my experience, software projects don’t live long enough to outgrow the MVP. If they do, it happens way down the road. At that point, business will change, and the original spec will become irrelevant.
It’s a paradox: 90% of the spec was discarded, but the business is happier than if we followed the spec word by word.
Also, static typing and unit testing solve nothing. I’m sorry.24 -
#1 life lesson I learned from coding?
Maybe not coding specifically, but I learned the difference between problem solving and solution finding.
Its helped me in a lot of areas of my life. Made friends and made enemies.4 -
#1 life lesson learned from coding:
Don't work on projects for the government or any authority EVER!6 -
When life brings you down and you think it can't get any worse.
Be positive and tell yourself, of course it can.2 -
Treat software development like a trade. Because it is one.
Would you hire someone to build a shed for you if you needed to supply the hammer and saw and they needed to read a "How to Build Sheds" book to just get started? No, you wouldn't.
So why would you hire someone that doesn't have any kind of ready-to-go dev environment?
Why would you hire someone that doesn't understand the basics of this field?
Why do you expect employees to stop what they are doing and teach the new guy everything he should already know, or be able to figure out on his own based on his own experience?23 -
Commit as you go. Work on one thing at a time. Be detailed in your commit messages.
Finding and reverting that one small change that breaks everything is so much harder to do when you change lots of files and the commit message is "update".2 -
Still water eventually starts to stink
keep moving. Keep your mind open. Always be the student. And the teacher [borrowed from kung-fu panda, though very valid in this context] -
#1 life lesson learned from coding: There are things I just can’t be good at no matter how hard I try.3
-
Just because it's popular, doesn't mean it's good.
An overengineered solution can usually be simplified without breaking anything important. An oversimplified solution can rarely be upgraded without major breaking changes.
Not everything needs to follow the "best practices" - if it's not a part of the core functionality, diminishing returns often kick in quite fast.2 -
You can comply with all the principles of clean architecture, but there will always be room for improvement in both performance and maintainability. The question you should ask yourself is when a software is ready to go into production6
-
Do what's necessary to solve the problem. A little more? Sure. But don't overdo it. That's true most of the time at least.1