5 ms·

I think the other key part of a senior engineers role is to ensure that product doesn't trump quality. When you have no senior engineers, what often happens is

by Niksko 7y ago

I think the other key part of a senior engineers role is to ensure that product doesn't trump quality. When you have no senior engineers, what often happens is without an advocate for doing things right, product 'wins', and teams turn into feature factories with little time for quality. Yes, quality is everyone's responsibility. But without an advocate with the right title and respect, it becomes secondary or even tertiary (behind velocity and features)

mooreds 7y ago
I agree entirely. > Yes, quality is everyone's responsibility. It isn't fair to expect someone to advocate for quality of something they can't see, and product can't see code quality. So, yes, someone in engineering needs to advocate for it. Here's a post I recently read about how the lack of code quality, among other things, nearly ran a good business into the ground: https://www.groovehq.com/blog/almost-walked-away https://www.groovehq.com/blog/almost-walked-away I have been in this situation myself (as have other commenters) and it's a balance between paying tech debt and moving product forward. Learning when to sit down and pay it, and how to communicate it, is an important part of being a software developer. Can't say I have mastered it.
ehnto 7y ago
I worked at an agency who's manifesto was built on quality over all. It permeated the culture and decision making. If we thought a particular way was the best approach but the client couldn't afford it, we would sometimes even split the cost as to avoid the cost of maintenance down the road. The clients were usually long term clients so this made sense. Eventually we grew to the point of needing some project managers and I learned so much about project management during that period. We had some that absolutely understood the ethos, advocated for the engineering team and communicated to the client why we do things the way we do. Then we had the PMs who saw the client as their paymaster, wanted to please them by making big promises, saw engineering as their personal work force, and were happy throwing engineering under the bus when it didn't work out. The worst work was done under the latter PMs and it always came back to bite us. Half baked features needing rewriting, third party modules hacked into the codebase, bugs and untested code needing weeks of client back and forth.

by Niksko 7y ago

mooreds 7y ago

I agree entirely. > Yes, quality is everyone's responsibility. It isn't fair to expect someone to advocate for quality of something they can't see, and product can't see code quality. So, yes, someone in engineering needs to advocate for it. Here's a post I recently read about how the lack of code quality, among other things, nearly ran a good business into the ground: https://www.groovehq.com/blog/almost-walked-away https://www.groovehq.com/blog/almost-walked-away I have been in this situation myself (as have other commenters) and it's a balance between paying tech debt and moving product forward. Learning when to sit down and pay it, and how to communicate it, is an important part of being a software developer. Can't say I have mastered it.

ehnto 7y ago

I worked at an agency who's manifesto was built on quality over all. It permeated the culture and decision making. If we thought a particular way was the best approach but the client couldn't afford it, we would sometimes even split the cost as to avoid the cost of maintenance down the road. The clients were usually long term clients so this made sense. Eventually we grew to the point of needing some project managers and I learned so much about project management during that period. We had some that absolutely understood the ethos, advocated for the engineering team and communicated to the client why we do things the way we do. Then we had the PMs who saw the client as their paymaster, wanted to please them by making big promises, saw engineering as their personal work force, and were happy throwing engineering under the bus when it didn't work out. The worst work was done under the latter PMs and it always came back to bite us. Half baked features needing rewriting, third party modules hacked into the codebase, bugs and untested code needing weeks of client back and forth.