5 ms·

I ran a software company and a team for 4 years, here's my experience: 1. I'm in this with Sloaken, it's about the money. Code artesans won't make it in the re

I ran a software company and a team for 4 years, here's my experience: 1. I'm in this with Sloaken, it's about the money. Code artesans won't make it in the real world. I mean, you might get very lucky and have a huge budget and all the time in the world, but unless you count on winning a lottery it's not happening. Deal with it, it's about making money with the code, not vice versa. 2. That one little extra thing you decided by yourself to code turned into 2 bugs, 4 feature requests, missing documentation and a duplicate tool library since another developer / team was working on something similar. In other words: don't go solo. 3. Getting shit done is the number one quality of a developer. 4. This is more towards designers but applies to developers as well: The customers' opinion about our UI/UX comes first, your opinion second.

scalesolved 8y ago
1. Totally agree, you've gotta work with constraints and engineers need to work towards generating revenue for the business as the primary goal. 2. 100% agree. 3. Getting shit done usually means things done shitly. It's the point you made I disagree with the most, whilst I understand the sentiment is towards engineers that complete tasks I feel that usually expressed this way (and coming from an engineering manager perspective) is that they favour the happy path engineer who completes tasks quickly. Need authentication in your app? They'll have it done quickly and it'll work for the manager happy path and they'll already be onto the next task. To the manager and whatever task tracker you have this engineer will be the 'one getting shit done' but to the team and velocity they'll be the one leaving exploits, broken functionality and zero tests/documentation. I'm guessing your sentiment was more along the lines of 'developers who pragmatically take on tech debt to deliver crucial features earlier to impact the business bottom line whilst planning to pay off the debt in a timely manner'. Long winded I know :) 4. This can be tricky, which customers to please and follow? A good designer allowed to come up with a consistent vision will most of the time be more productive/pleasing than following the changing opinions of your customer base.

scalesolved 8y ago

1. Totally agree, you've gotta work with constraints and engineers need to work towards generating revenue for the business as the primary goal. 2. 100% agree. 3. Getting shit done usually means things done shitly. It's the point you made I disagree with the most, whilst I understand the sentiment is towards engineers that complete tasks I feel that usually expressed this way (and coming from an engineering manager perspective) is that they favour the happy path engineer who completes tasks quickly. Need authentication in your app? They'll have it done quickly and it'll work for the manager happy path and they'll already be onto the next task. To the manager and whatever task tracker you have this engineer will be the 'one getting shit done' but to the team and velocity they'll be the one leaving exploits, broken functionality and zero tests/documentation. I'm guessing your sentiment was more along the lines of 'developers who pragmatically take on tech debt to deliver crucial features earlier to impact the business bottom line whilst planning to pay off the debt in a timely manner'. Long winded I know :) 4. This can be tricky, which customers to please and follow? A good designer allowed to come up with a consistent vision will most of the time be more productive/pleasing than following the changing opinions of your customer base.