4 ms·

I don't consider myself as experts compare to some of the big names, but my habits have served me well. 1. Don't assume anything. Go in with an open mind and b

by aynyc 5y ago

I don't consider myself as experts compare to some of the big names, but my habits have served me well. 1. Don't assume anything. Go in with an open mind and blank canvas. I can't tell you how many times I've been in design meetings where engineers assume they know how things are gonna work, before clients even open their mouths. I can't tell you how many times clients assume they know how technology works before we explain to them. 2. Iterate and validate as fast as you can within reason. Don't do waterfall, at least not at the beginning. Design, build and validate, or even just do napkin design and validate. It'll save you a lot of headaches. 3. Perfect is the enemy of good. When you reach a certain comfort level with your software, ship it. You'll never be able to clean out your tech backlog or bug list.

hugey010 5y ago
#3 is very true, but where is the line? If your website crashes on every request, then it's clearly not ready. If it crashes only on Thursdays when Carl uploads that one spreadsheet, it depends how important Carl's spreadsheet is. The answer is always, it depends. When SLA requirements are nonexistent, or self-defined, what is good enough?
- aynyc 5y ago
  If Carl is uploading financial reports or payrolls for the CXO every month TWICE, then I'll just make sure I have a script that can handle that file unless the fix is easy. If you have SLA, that's easy, ship as soon as you hit that SLA. If you don't, then onboard clients very carefully.