Skip to main content

Can You Code A Design? - Part Two

2 mins 📖 

design

Last time I wrote about coding up a design, I was only two weeks into the related project. Now, it has been weeks since I finished and I am documenting the remainder of my scribbled-down points in the event that I or someone else might find them useful in the future. The below points are formatted exactly how I wrote them in the heat of varying degrees of exasperation - enjoy!

  • Check the most minimal thing you can do to get it out the door.

  • Check with more than one person on specs!!! - one person may say you need something, another says you don’t etc.

  • Heavily scrutinise the design for common design patterns and put these into your globals. Ask designers whether these are likely to change.

  • PAIR PROGRAM WITH THE OTHER DEVELOPER FROM THE BEGINNING!!!!

  • Make sure each dev respects coding, commenting and reviewing practices (this can be super hard).

  • Don’t trust that you have the correct information. Communication between individuals in the project isn’t always perfect. Speak to each team member you work with. Ask them what they’re up to, share successes and information. You might (correction - probably will) find that they haven’t been given enough information by the PO and are stuck. You can then give them the required information, making everyone happier and less stressed. In short, over communicate rather than under communicate.

  • Get info you need before people go off on holidays.

  • Smile and be nice, it might make someone’s day or make their job easier or more pleasant. Be to others how you wish others to be to you.

  • Get automated testing in, don’t throw stuff at QA engineers and say “If the QA engineers say it’s fine, push it to production”.

  • Get some decisions for padding, fonts, colours and spacing in early people COME ON!!!

Buy me a coffee ❤️

0 Responses