Following on from Ben's post I thought it might be interesting to turn the question around the other way...
Looking forward to the discussion.
Following on from Ben's post I thought it might be interesting to turn the question around the other way...
Looking forward to the discussion.
For further actions, you may consider blocking this person and/or reporting abuse
vamstroy -
Chris Jarvis -
Peter Kim Frank -
Michael Tharrington -
Top comments (2)
Everywhere that I've worked has been a 'prove that it works before you deploy' kind of workflow. 'Move fast and break things' has merit. It's really hard to make enterprise companies understand the value of rapid prototyping something just to see what happens before putting something into primary flow. You still want to prove things, but if you are risk adverse then you will have a significantly harder time achieving greatness.
Fairly obvious one this, but often indie developers learn to do things their own way and explore alternative solutions rather than following mainstream 'wisdom' and practice. Results can vary, but there's certainly way more job satisfaction along this route