3 ms·
Also learn how to run a business. A weird suggestion on the surface but actually very powerful when understood. In short by learning how a business operates, h
by movedx 7y ago
Also learn how to run a business. A weird suggestion on the surface but actually very powerful when understood.
In short by learning how a business operates, how cash flows and how expensive things are (people, buildings, software, hardware, accountants, lawyers, ...) you'll begin to understand why an MVP is a powerful tool. you'll also appreciate Agile development practices more too.
With an MVP you're writing the least amount of code possible, and skipping optimisations, whilst also providing some value to people who can tell you what direction to go in next. That's a business thing - the business needs something in the market ASAP and it needs feedback ASAP. Without this you'd write your stack for three years and then release to a world that moved on two years ago.
When you learn how a business is run you begin to understand that getting to market with a less than ideal code base is actually desirable and something to embraced. All of sudden you'll come to understand that money burns quickly so you should learn to develop code to get to market and not to be the fastest code it can be (yet, at least.)
I find the best programmers I've worked with are those that can produce something quickly and optimise it later on.
- einpoklum 7y agoI've found the ability to produce something quickly is almost orthogonal to being a "good programmer" (unless you define goodness that way.) Some are good quick-and-dirty implementers, some are deep design thinkers, some are just good at reviewing and giving advice.
- ratww 7y ago> Some are good quick-and-dirty implementers, some are deep design thinkers, some are just good at reviewing and giving advice. Fred Brooks has a chapter in Mythical Man Month where he mentions different programmers having different roles within "Surgical Software Team" but that never took off. I wonder if updating that to 2020 would make more sense to have a group of people shipping features full-steam ahead, another reviewing the code for mistakes, and then having other folks refactoring the mess, behind both of them. I would frankly enjoy being in just one the three positions, any of them, much more than the position I'm currently: having to be all three at the same time.
- kqr 7y agoThis is an interesting idea. I've frequently found myself in the slow and methodical camp, but I admire the way in which one of the co-founders at my current job can just throw together some amazing proof of concepts in very little time. Of course, the code they write is in general littered with assumptions, missing error handling, and potential performance problems. I hope I'll be able to learn that part of it too, but perhaps I am more naturally inclined towards writing the second version of their MVP instead.
- hanifc 7y agoI've often thought about a similar idea. I'm still relatively new to the industry (3 years programming, 1.5 professionally), but I've found that I'm a BIG fan of refactoring. To me, it's like writing or communicating ideas in general, which I really enjoy. I love taking a complicated idea and trying to explain it in the most simple and readable of terms. It also pushes me to really understand the intent behind the code/text. To that extent, I enjoy editing and revision much more than creation. So, taking a role as a 'refactorer' actually sounds great!