For me, web engineers are the magicians behind the curtain. That can mean not-a-lot of glory.

But for engineers like myself, undone engineering is more painful than unsung engineering.??One of the most difficult aspects of being a good engineer is knowing when to sacrifice good engineering. ??Startups, are by definition, challenging the established way of doing business, so the established way of doing great engineering sometimes isn’t good enough to survive. ??

Everything in a startup changes fast.??Engineering is managed chaos.??There are new team members, new customers, new data, new open source libraries, etc. Good engineering can accommodate change, but usually change is unexpected. As a side effect, the non-technical team begins to depend on the shortcuts, and the shortcuts begin to show their weaknesses. The design team has new ideas, and you can’t say yes as often as you used to.??

But you survive.??

Here are the priorities I use to keep everything moving for a web application startup (follows an 80 / 20 rule pretty well):

1. protect the data (files/database, etc)
   1. back it up
   2. make sure data is valid (ideally some smoke tests, unit tests, regression tests on the data layer of an application)
   3. back it up
   4. source control with easy to understand policies and branching
   5. back it up
   6. automate backing it up
2. fix problems with the user experiences
   1. small visual problems can make people … disgusted. Fonts, cross browser issues take a lot of time, but matter to people who expect things to work.??
   2. client (browser) speed – a small javascript issue can cause a page load to appear to take 5 seconds. Perceived performance is all that matters.??
   3. fix display issues – if they think data is lost, then it is??
   4. integrated QA team – make everyone on the team test the site, but not their own work.
3. make coding fast
   1. establish team communication that makes product iteration rapid
   2. use frameworks, existing but stable libraries (open source so you can fix critical problems yourself)
   3. keep version control and deployment as automated as possible for the whole team
   4. write easy to understand code
   5. document code and best practices (wiki style)
   6. track problems (bugs and backlogs)
   7. write test code (on critical areas)
4. housekeeping
   1. refactor
   2. cleanup
   3. more test code
5. new features/ scaling/performance??- probably the most fun for an engineer, but last on the list. This has been the hardest for me. ??Engineers need to think about scaling when the system is architected…. maybe. But when you have just a 10 customers and the entire database fits in memory… why worry?
   1. database ??- a typical bottleneck. NoSQL and distributed architectures are making this easier
   2. separate web server from application layer. Concentrate core application logic into languages that are better suited for scaling and concurrency issues
   3. load balance, messaging queues, etc