There’s lots of good stuff in here; it’s a mix of war stories and great thoughts. All the italics and emphasis are mine. There really is a lot of good writing in here and it’s a great little book to read. I highly recommend it and only wish the author had put it into book format. Great quotes all around.
What Makes One Software Engineer Better Than Another?
If working in production is not a good determinant, what makes one engineer better than another?
Fearlessness is a good marker in my opinion…
So what is it to be fearless? It is jumping in to get stuff done, because it is the right thing to do, and doing it no matter what the technology; Java, C#, Python, Perl, Bash etc. Engineers that do that and think like that are valuable.
Don’t Go Cheap
Lifelock made several attempts to get in cheaper and less experienced engineers to do bug fixing and production support…We have trouble getting senior engineers to write good code and understand our system, what chance does a production support engineer have?
Give The Engineers Freedom To Do Everything To Get The Job Done
The reality is you have to get good engineers and pay them well, you then have to let them do everything. Features, Quality, Production Support, Automation, Functional Tests, Release, Ops; everything. It is the only way you get it all done. You even have to give them root or admin privileges and let them maintain non production environments. Again, you just have to let them go and do everything.
Letting software engineers do whatever it takes to get the job done does not mean doing extreme amounts of overtime, it means being able to walk into the deployment shell scripts and fix them and then go back to the frontend/UI code and fix that when it’s broken or add new features. I think this is why there’s been an increase in the term “full-stack” though there are still a lot of restrictions placed on those full-stack engineers.
For instance, on one project our deployment was constrained because we relied on one person to set up the deployment process. When the deploy process didn’t work, the deployment dev had to fix things because no one else had the permissions necessary to do so. If he went on vacation or had other projects to work on, our project was out of luck.
In many cases I’ve been in a situation where I was working on the frontend web application team and ended up waiting anywhere between two days to two weeks to two months for some backend API methods to be implemented. Because the frontend team was shown how to deploy the backend and wasn’t show how to work within the code, there was no way to speed things up. I ended up faking things and creating stubs. Not always an ideal situation.
Engineers Should Report To Other Engineers
You also need engineers to run engineers. If an engineer is running other engineers then there is no he said, she said. Both of you are in the code all day, in the source repository all day and you cannot pull the wool over the eyes of someone who is coding side by side with you. Specialist managers don’t work with software. For starters they make technical decisions they have no business, right or legitimacy to make. They don’t really know and they don’t have the eye to see what is right and what is wrong.
If you’re going to be a manager of software developers, and you aren’t a software developer yourself, you absolutely have to get into the technical details and ask as many questions as possible and learn as much as possible. If a software engineer is telling you one thing, you should look into it and ask another software engineer’s opinion on it. This is vital when there are deadlines in the mix.
Later on in the book he says:
Managers that are not software engineers tend not to understand the system from the software angle no matter how strong their technical skills are, so a lot of bad architectural or refactoring decisions are made by the manager and are then implemented by junior software engineers who don’t understand the errors the manager is making. Alternatively the junior engineer doesn’t feel empowered to point out the error or go against that design decision.
This is a common issue:
Another issue is weak managers that say yes to every date no matter who achievable or unachievable it is that leads to time pressures and code being pumped out with highly variable quality just for the purposes of that date being hit. There ends up being a group consensus there that it is unhittable but teams don’t want to say that it is impossible, or if they do, they keep that opinion within the cube farm and it doesn’t get to the upper manager who thinks they are getting an artifact on a certain date. I have seen this called the “thermocline of truth”.
The issue of the manager who always says yes is something I’ve seen at agencies because there’s executive pressure and client pressure to get the project done and get paid.
Technical Decisions Taken For Social Problems Can Be Inappropriate
Employees want to do the right thing, they want to do well, so let them. Just because an ACL list lets you be absolutist about doesn’t make it the right choice. A few kind words are often better in achieving a technical outcome.
Develop Better Relations With Other Groups & Departments
We started developing better personal relationships with the other groups which sped things up and largely stopped, the “put a ticket in so I can work on it” style of inter-organizational communication.
Forcing other departments and project groups to go through your ticket tracking tool to get anything done doesn’t make for good social relations.
Tools Make A Difference, Bad Tools Will NOT Be Used
Tools do make a difference. If it is a crappy tool no-one will use it. The group communicator product was crap and so no-one used it for communication even though it would have been of benefit. There was a similar issue with the wiki. We were pretty much a Windows shop in most areas of IT and the sharepoint site was supposed to be used by everyone. Engineering and Infrastructure preferred a wiki, but we could not get one into the organization. There was one aborted try when an Apple wiki was rolled out, but it was crap and hard to use, so no-one did.
Code Written With Unit Tests Looks Different From Code That Has No Unit Tests
Software engineers that don’t unit test produce code that is remarkably different to those that do. This makes it appear like their are two different software systems being written within the one class. Michael Feathers in “Working Effectively With Legacy Code” describes legacy code as ‘code without tests’.
What You Can Say To Make Life Less Stressful
Software is only partially stressful for the technical side of things. Any business is a social operation and navigating personalities is very important. If there is one piece of good advice I can give it is that saying no is ok. It is alright to say I can’t give you a date because I don’t know. It is also acceptable to say I can give milestones but not a date as there is just too much volatility to know. That is enough for the planners who have to orchestrate marketing, member services and all the other arms of a company that need to know what is going on. It is also ok to say I am not working weekends. We did this, and again, nothing happened, none of us got fired.
The Three Year Cycle
By the end of three years I was doing the same things each day that I had been doing for a while and the technology was not going to change in the near future so I was starting to get bored. Three years is a cycle in the technology industry. After about three years people start to move on, to new opportunities, new technologies or just a change for the sake of it.