4 ms·

What I do in this "war" is constantly reminding and educating my coworkers that they should care more and also teaching them HOW they can do that. I had alread

by Walkman 10y ago

What I do in this "war" is constantly reminding and educating my coworkers that they should care more and also teaching them HOW they can do that. I had already several very hard and harsh fights with my bosses, even with the CEO telling them "everyone is not very good at this company" because I care about quality very much and rather fight over it than sit quietly and just produce shit. I gave "talks" about specific topics, constantly grab the opportunity when I can tell them about a new concept, Clean Code, better tools, whatever. I introduced TDD, CI, automatic deployments, will introduce CD next month over a year I have been working at my current company. If you are one of the better developers you can and should fight against lazyness and low quality, even teach the ones who cares/know less. Also it's very comfortable to blame your boss, but you can do very much about this. I introduced automated testing not because they asked me for it, but because I thought is important. I educated them that this way, development will take a bit longer, but will be higher quality. You can even do things which improves quality and they don't even know about. My next step is to introduce third party services (which they never used before and always went with the open source or cheap solutions) which makes our work easier, so we can focus on what's important, and make it better.

pdkl95 10y ago
> If you are one of the better developers you can and should fight against lazyness and low quality This can be thought of as a type of error correction. If you don't fix problems as they rise up the chain of command, those problems eventually become policy. http://ogun.stanford.edu/~bnayfeh/plan.html http://ogun.stanford.edu/~bnayfeh/plan.html (mild language warning, of the form "____ happens")
hrnnnnnn 10y ago
Totally agreed. In my experience, engineering improvements are always a bottom-up thing.
stunthamsterio 10y ago
I can't agree with this more. Apathy and clock watching has done more to damage our industry than many other things. It shocks me when developers are willing to do the bare minimum, scrape by and avoid arguing to make things better. Much like the OP, I spend a great deal of time trying to guide my clients to work in ways that guarantee better quality. The mantra in a lot of these places though is 'Features first, feature bug fixes second, other improvements never'. Without the folks delivering the software (Everyone from QC, DBA's, DevOps Engineers/Ops and Developers) pointing out the inherent danger in this nothing is going to change.
d2p 10y ago
I totally agree, and since I became team leader where I work I like to think we've made MASSIVE strides in quality. We've moved from CVS (lol) to DVCS; we review every checking; we have build servers and perfectly matching local QA and production staging environments. We devote time to fixing bugs and eliminating technical debt. We're still far from perfect, but I we're definitely on the right track. It's possibly because we try so hard to improve that I get so frustrated when big companies appear not to :(
steveoc64 10y ago
Wow - good stuff, and keep up the good fight. I don't have that many people around me that are worth influencing directly, so here is the way that I do it : 1) I divide up the TODO list and customer requirements into the 'Little Things' and the 'Big Things'. 2) Customers / Managers / Users seem to love the 'Little Things', and feel like they are getting great value for their dollar when so many of the 'Little Things' can be delivered in a relatively short time, it looks like great progress to them. 3) I always do the 'Little Things' at the Customer's site, in the Customer's presence. I always do them during the day, and I get the managers involved as much as possible. Be a good corporate citizen, and get paid on time. 4) Doing lots of little things on an hourly rate is a good way to generate cash quickly, and get paid on time. Its useless in the grand scheme of things in terms of software development, but it is needed to keep everyone happy and ensure that you can pay the bills on time. As you can see, this is all about cash, fast cash, and smiles and happy customers all around. It can be borderline degrading at times, but there you go. Milestones and Invoices and Smiles, and more Smiles and Cash. 5) I don't even bother trying to explain the 'Big Things' to these same Customers / Managers / Users, because it just plain scares them. They will never believe that software can ever be that complicated or difficult. It really scares them in fact. They want their world to be manageable, understandable, easy to estimate, easy to achieve ... that want to feel like they are 100% on top of things and in control. So I just don't talk about the 'Big Things' at all. Peering into the void that is the Big Things is the quickest way to make a Happy Customer (who pays on time at a good rate), into a very upset individual. 6) Bank the money and take time off. Turn off the phone, close the email app, stock up the fridge, tell people you will be out of town for a while. Get comfortable .... and code. Code the big things. Do it in the comfort of your own setup, away from everyone, and take your time. No deadlines, no clocks, no timesheets .... just you, an editor, a github account, some emergent ideas that may or may not be well defined, and some code. Working on the 'Big Things' is simply not negotiable. I never charge for doing the 'Big Things', and I never discuss this with customers, or try and use it as leverage in future billing arrangements. Working on the 'Big Things' is simply not negotiable. Working on the 'Big Things' is why I program and why I ever started to get into this in the first place. Being able to properly immerse myself in the Big Things, on my own terms, on my own time, out of my own pocket ... is compensation enough, and worth far more to me than any paycheck ever will be. Working on the 'Big Things' is simply not negotiable. Having a set of 'Big Things' in my toolbox then enables me to re-enter polite society for a while, in order to crank out some more 'Little Things' easily and cleanly, and get the bills covered. You need happy customers for that. Happy customers with Milestones and Ticks in Boxes and Smiles and Invoices and Cash on Time. But working on the 'Big Things' is simply not negotiable.

by Walkman 10y ago

pdkl95 10y ago

> If you are one of the better developers you can and should fight against lazyness and low quality This can be thought of as a type of error correction. If you don't fix problems as they rise up the chain of command, those problems eventually become policy. http://ogun.stanford.edu/~bnayfeh/plan.html http://ogun.stanford.edu/~bnayfeh/plan.html (mild language warning, of the form "____ happens")

hrnnnnnn 10y ago

Totally agreed. In my experience, engineering improvements are always a bottom-up thing.

stunthamsterio 10y ago

I can't agree with this more. Apathy and clock watching has done more to damage our industry than many other things. It shocks me when developers are willing to do the bare minimum, scrape by and avoid arguing to make things better. Much like the OP, I spend a great deal of time trying to guide my clients to work in ways that guarantee better quality. The mantra in a lot of these places though is 'Features first, feature bug fixes second, other improvements never'. Without the folks delivering the software (Everyone from QC, DBA's, DevOps Engineers/Ops and Developers) pointing out the inherent danger in this nothing is going to change.

d2p 10y ago

I totally agree, and since I became team leader where I work I like to think we've made MASSIVE strides in quality. We've moved from CVS (lol) to DVCS; we review every checking; we have build servers and perfectly matching local QA and production staging environments. We devote time to fixing bugs and eliminating technical debt. We're still far from perfect, but I we're definitely on the right track. It's possibly because we try so hard to improve that I get so frustrated when big companies appear not to :(

steveoc64 10y ago

Wow - good stuff, and keep up the good fight. I don't have that many people around me that are worth influencing directly, so here is the way that I do it : 1) I divide up the TODO list and customer requirements into the 'Little Things' and the 'Big Things'. 2) Customers / Managers / Users seem to love the 'Little Things', and feel like they are getting great value for their dollar when so many of the 'Little Things' can be delivered in a relatively short time, it looks like great progress to them. 3) I always do the 'Little Things' at the Customer's site, in the Customer's presence. I always do them during the day, and I get the managers involved as much as possible. Be a good corporate citizen, and get paid on time. 4) Doing lots of little things on an hourly rate is a good way to generate cash quickly, and get paid on time. Its useless in the grand scheme of things in terms of software development, but it is needed to keep everyone happy and ensure that you can pay the bills on time. As you can see, this is all about cash, fast cash, and smiles and happy customers all around. It can be borderline degrading at times, but there you go. Milestones and Invoices and Smiles, and more Smiles and Cash. 5) I don't even bother trying to explain the 'Big Things' to these same Customers / Managers / Users, because it just plain scares them. They will never believe that software can ever be that complicated or difficult. It really scares them in fact. They want their world to be manageable, understandable, easy to estimate, easy to achieve ... that want to feel like they are 100% on top of things and in control. So I just don't talk about the 'Big Things' at all. Peering into the void that is the Big Things is the quickest way to make a Happy Customer (who pays on time at a good rate), into a very upset individual. 6) Bank the money and take time off. Turn off the phone, close the email app, stock up the fridge, tell people you will be out of town for a while. Get comfortable .... and code. Code the big things. Do it in the comfort of your own setup, away from everyone, and take your time. No deadlines, no clocks, no timesheets .... just you, an editor, a github account, some emergent ideas that may or may not be well defined, and some code. Working on the 'Big Things' is simply not negotiable. I never charge for doing the 'Big Things', and I never discuss this with customers, or try and use it as leverage in future billing arrangements. Working on the 'Big Things' is simply not negotiable. Working on the 'Big Things' is why I program and why I ever started to get into this in the first place. Being able to properly immerse myself in the Big Things, on my own terms, on my own time, out of my own pocket ... is compensation enough, and worth far more to me than any paycheck ever will be. Working on the 'Big Things' is simply not negotiable. Having a set of 'Big Things' in my toolbox then enables me to re-enter polite society for a while, in order to crank out some more 'Little Things' easily and cleanly, and get the bills covered. You need happy customers for that. Happy customers with Milestones and Ticks in Boxes and Smiles and Invoices and Cash on Time. But working on the 'Big Things' is simply not negotiable.