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
Ben Halpern -
Ben Halpern -
Roger Oriol -
Somil Gupta -
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