Regardless of tech and challenge-specific context, what overarching principles do you come back to?
For further actions, you may consider blocking this person and/or reporting abuse
Read next
The story behind John Doe
Muhammad Essa -
What’s the Best Way to Market Your SaaS as a Solo Developer?
Dusan Petkovic -
From Idea to Launch: Mistakes to avoid in your Development process
Namubiru Rose -
Why Cookie-Less is the Future for Tracking Analytics in Europe (and the World)
Antonio | CEO at Litlyx.com -
Top comments (36)
For me, I often go back to this Alan Kay quote:
To me it basically describes all great software.
The Commandments of a Great Frontend Developer
Understand the customer's actual problem, not the request specs.
Organization is hard and important to get right, so invest effort into it. When you put something in the wrong place it creates non-trivial, unnecessary overhead on future work. This applies to architecture, lines of code, and even the company itself. This is why "refactoring" (reorganizing) is important. Otherwise, the effort of overcoming disorganization eventually dwarfs forward progress. Aka "technical debt", only it is not really technical.
Production code is the only code you can count on. When it is in production, you have a feel for how much it costs to operate and maintain. Until then, it is guesswork and you cannot rely on it. As much as is possible, focus on releasing features incrementally to production instead of going dark for long periods of time. For new projects, deploy something simple and iterate. Building something complex to start is a losing proposition... unless you already have working production code you can use as a template.
Invest lightly in technologies but heavily in skills and understanding. Techs come and go constantly. Knowing a framework inside and out may be entirely wasted effort after a few years. But skills and logical concepts can serve you for many years to come. In practice, this means I prefer simple libraries where usage is obvious instead of frameworks with lots of abstractions. This also informs my preference for functional programming, because abstraction is minimized, and if you want to get into abstractions, they are based on provable/reusable mathematical properties... not some random opinion of the language/framework writer.
Be good to work with. You will never succeed without the cooperation of other people. There is no point in fighting this inevitability. Instead, work on improving yourself so that you can make the best of it. I am deeply introverted, so if I can learn enough to get by in this area, I know you can too. That classic book How to Win Friends and Influence People is a great starting point.
If I had to chose one principle to be my guiding principle, I would go for
KISS - Keep it stupid simple
Most of my career, I've been fixing / debugging other people's creations. And this taught me the lesson that it does not pay to be (too) clever.
Build systems mostly with primitives and simple abstractions helps avoiding errors easily and saving time and energy.
Or how Brian Kernighan once put it:
»Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?«
Slow down, take the time to do things right. You'll end up going faster in the end.
Numerous projects I've worked on with this in mind seemed to have really slow progress in the beginning, but really fast progress towards the end. In all cases we've always hit our initial timeline goals, but exceeded expectations on follow-up work.
That is indeed a good approach but as I had experimented in a lot (too many for sure) of organizations, you are too often force to rush on things because of business deadlines, promises made (not by the devs) to the upper management, and the list could go on and on.
So if your Product Owner, Stakeholders, etc... are not from technical background you are going to have a hard time.
So I found it very useful to make quick Brown Bag Lunch open to everyone, so that anyone, from technical background to marketing etc can join, have fun and have a better understanding about what it takes to develop something. But as it is not the end, debug it, test it, deploy it, etc...
It is very helpful for everyone. And then if everyone speak a common language it makes things easier and we can tend to take the time to do things right so that we can go faster in the end.
Yeah and do TDD.
I disagree with TDD. Sure write tests for your things, but TDD is just kool-aid that caught on in early 2013. Academically it makes sense, but in reality it's not practical.
My guiding principles:
Shorten feedback loops
Work iteratively and deploy small changes whenever possible. Catch errors as early as possible, and don't allow minor failures to become major ones. Minimise the cost of experimentation. Also don't force users to fill out lengthly forms and then present them with a bunch of errors at the end. This makes me sad.
Bias for action
This is stolen from amazon. It means don't spend a lot of time making decisions if the decisions are easily reversible.
If teams are quite risk averse they can default to having a meeting about everything. I can also slow things down by overanalysing something or thinking I need permission/buy-in to do something. Sometimes you just have to assume the answer will be yes, and ask things like "what if we just did X" to get things moving. If you're not sure if something will work, build a prototype and find out.
Minimise the amount of work in progress
Finishing things is more important than starting things. Avoid juggling multiple things at the same time, and try to resolve blockers as soon as possible. If you have to change what you're working on, be explicit that you're stopping working on the old thing to work on the new thing so managers understand why stuff isn't getting done.
When you are about to start a new thing, that's a good time to help other people finish their stuff, for example by pairing with them or reviewing their code.
Don't refuse requests for help
If someone asks you a question you can't answer, don't just say "I don't know" or act like it's not your problem. Help them find someone who can help them or suggest ways they can find the answer themselves.
Don't try to do everything by yourself
Know when to ask for help. If the site is down and you can't fix it in 5 minutes, get other people in involved in investigating or communicating what went wrong. Even if it's just someone to bounce ideas off of. If you're stuck on something for more than a couple of hours, ask someone else for advice - it will probably be a learning opportunity for both of you.
Also, don't become a single point of failure for your team. You should be able to go on holiday without the team grinding to a halt because only you know about something. Write code that is easy for your team/the future team to maintain.
Ask stupid questions
Stupid questions are useful for gaining insight. They can also prompt further discussion and force people to explain stuff in plain english.
It should always be ok to ask why you're doing something or why a more naive solution won't work. If someone explains something and it's slightly unclear, don't assume you understood it correctly, check your understanding with the other person by repeating it back to them.
Assume good intentions and learn from failure
Follow the retrospective prime directive. If something bad happens, focus less on the people and more on the systems, processes, and incentives that enabled it to happen.
If you have problems with someone else's behaviour, don't ascribe emotions or motivation to them. Talk about the things they objectively did, what the impact was, and what they could do differently. Find a way to be assertive without necessarily reacting in the moment.
Document anything important
First and foremost for me, understand who wants what, and why. Take it slow and steady, I'd rather take 10 extra hours and have it "perfect(1)" than skip 20 hours and only half work. Don't write sixteen layers of abstraction, you'll give yourself and other developers a headache; if you don't need it, don't do it. Finally, take 30 seconds and write a comment somewhere about why you wrote that file/line/n... etc, it saves time for future developers not having to guess! Nice to have for me is a "maybe later" - it'd be nice to have a lot, but let's focus on what we need to have
(1) perfect, understanding there is some minor bugs, but the functionality is implemented to the best of my ability
I'm getting better at writing comments and commit messages about the why. The how is in the diff :-)
I found this on Twitter recently but this for sure is one of the principals I will follow.
There is no right answer or one true way.
Every time I think "Aha! This is how you do software development!" I run into someone who's very good at their job who doesn't do it that way. Ultimately I just strive for quality.
Change is the constant in this world.
So, developing applications that can easily adapt the changes and can be easily extended is the key factor in software development.
Always keep in mind that anything you make is should be easily configurable.