DEV Community

Discussion on: What are your guiding principles in software development?

Collapse
 
matmooredev profile image
Mat • Edited

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

  • Use architecture design records to document major technical decisions
  • If the domain is really complicated, draw diagrams that simplify it
  • Make an onboarding guide for new starters
  • Make a playbook for supporting your product in production
  • When investigating a thing, write down what you learned, then present it back to people