1) its not personal, its about the money.
thats why we have to do this / that etc, and not this or that
2) everyone is replacable (or will choose to leave at some point) - make your code / system / database in such a way that your replacement admirers you for the clarity of your documentation, not hates you for that clever trick you implemented. Corollary: all code that is not well documented is throw away crap when you leave.
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.
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.
It takes a lot of work to make a technology production-ready. I've seen MySQL go from being derided as a toy database, to powering some of the largest, highest scale consumer apps out there. It took years of work from both the core teams, and many contributions out there from people working with it every day to make that possible. It's important for engineers to know their history when they pitch the latest tech they read about on HN and ask why they can't use it on a new project at work. The fact that you can get it up and running isn't enough, you need to be able to keep it running. If you aren't willing to put in that work, then don't pitch the tech.
Secondly, emergent architectures are often more resilient than deliberate architectures. Frameworks and platforms extracted out of real products tend to have more longevity behind them than those that are deliberately designed to solve a multitude of needs from day one. If it doesn't feel right to bring a library or platform in to solve your problem (rather than build something yourself), then don't do it. You might find yourself spending more time fighting the platform or bending it to your will than by building something by yourself.
There are five things I wish developers with whom I work understood:
1) At the end of the way, we're a business. The purpose of the business is to make money. Not work on cool things, not release a cool product, but to make money. It's not about experimenting with the latest, greatest technology all the time. If we don't make money, you don't have a job.
2) I'm juggling a lot of priorities, and I've _always_ got the bigger picture in mind. The tasks I assign you might seem dumb or not useful in the moment, but trust me, either someone is _paying us to do this_ or gets us closer to a goal on our roadmap.
3) I believe as engineers that we have a unique skillset among most people in our respective industries: we can automate repetitive tasks. Automate all the things. Most of the time, it will make all of our lives better.
4) As a corollary to #3, I wish more developers were willing to adopt a mindset of being willing to shoulder more work to make their colleagues lives easier. In 95% of cases, I would rather that my team take on the burden of doing X, Y, or Z, because I know we can automate it. Not only does this earn goodwill among the rest of our company, but it makes us look like absolute powerhouses of engineering.
5) Delete the phrase "it works from me" from your vocabulary. People don't complain about things that work for them. If it works for you but not them, then there are two possibilities: there's a bug or the user is doing something wrong. _Always_ assume that there is a bug, unless proven otherwise. It's just good, professional communication policy.
1) its not personal, its about the money. thats why we have to do this / that etc, and not this or that
2) everyone is replacable (or will choose to leave at some point) - make your code / system / database in such a way that your replacement admirers you for the clarity of your documentation, not hates you for that clever trick you implemented. Corollary: all code that is not well documented is throw away crap when you leave.
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.
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.
It takes a lot of work to make a technology production-ready. I've seen MySQL go from being derided as a toy database, to powering some of the largest, highest scale consumer apps out there. It took years of work from both the core teams, and many contributions out there from people working with it every day to make that possible. It's important for engineers to know their history when they pitch the latest tech they read about on HN and ask why they can't use it on a new project at work. The fact that you can get it up and running isn't enough, you need to be able to keep it running. If you aren't willing to put in that work, then don't pitch the tech.
Secondly, emergent architectures are often more resilient than deliberate architectures. Frameworks and platforms extracted out of real products tend to have more longevity behind them than those that are deliberately designed to solve a multitude of needs from day one. If it doesn't feel right to bring a library or platform in to solve your problem (rather than build something yourself), then don't do it. You might find yourself spending more time fighting the platform or bending it to your will than by building something by yourself.
1) At the end of the way, we're a business. The purpose of the business is to make money. Not work on cool things, not release a cool product, but to make money. It's not about experimenting with the latest, greatest technology all the time. If we don't make money, you don't have a job.
2) I'm juggling a lot of priorities, and I've _always_ got the bigger picture in mind. The tasks I assign you might seem dumb or not useful in the moment, but trust me, either someone is _paying us to do this_ or gets us closer to a goal on our roadmap.
3) I believe as engineers that we have a unique skillset among most people in our respective industries: we can automate repetitive tasks. Automate all the things. Most of the time, it will make all of our lives better.
4) As a corollary to #3, I wish more developers were willing to adopt a mindset of being willing to shoulder more work to make their colleagues lives easier. In 95% of cases, I would rather that my team take on the burden of doing X, Y, or Z, because I know we can automate it. Not only does this earn goodwill among the rest of our company, but it makes us look like absolute powerhouses of engineering.
5) Delete the phrase "it works from me" from your vocabulary. People don't complain about things that work for them. If it works for you but not them, then there are two possibilities: there's a bug or the user is doing something wrong. _Always_ assume that there is a bug, unless proven otherwise. It's just good, professional communication policy.
Quite a few are like robots that needs to be told what to do to the letter.