I have worked at a number of companies over the last few years. All of them start off looking good but most fall into the “I wish I hadn’t wasted x years/months of my life here”. “How did this happen again?” I’ve wondered. I naturally missed the early warning signs which I should have heeded. I’ve chosen to document some of the most frequent occurring warning signs and lessons learned in the hope of reminding myself to steer clear of certain Companies. I also hope that my lessons will aid you in not repeating them.

Ask better interview questions

Most developers never ask a prospective employer any useful questions. We might ask about technology. We might ask about the problem being solved. We negotiate salary. Rarely have I heard a developer ask more than that.

The interview is the best place to weed out jobs that are going to suck later. Just like in Kanban a problem is a lot easier to fix at the source of the problem rather than further down the process chain.

Here are some practical questions to ask:

  1. Ask questions about the methodology. What happens when there are changes? What happens when new requirements are added? How are stories estimated? Who estimates them? How many stories were not implemented in the last couple of iterations?
  2. Ask about the development process. This would include TDD, pair programming, integration testing, build systems, CI, the process by which artifacts are moved to production.
  3. The technical interviewer is likely to be one of the more skilled members of the team. Find out about any technical books he is reading, opensource contributions, any new languages and frameworks he is using/learning and any conferences he has attended in the last few years. Is he constantly improving?
  4. Find out how the position you are applying for became available. Are lots of people leaving the Company?
  5. Ask about some of the technical challenges they currently face. Then ask about some solutions they have in place.
  6. Ask about some improvements they have made between the last few iterations.
  7. Ask them what the biggest hurdle to productivity is at the moment.

Don’t be afraid not to accept a job, if you feel that the answers to some of the above are sketchy. It’s easier to walk away now.

During one job interview, the technical teamlead mentioned things like: “40 developers have worked on the codebase in the last 4 years - and it shows”, “I’m struggling to get the number of unit tests into double digits” and “the project is 4 years late but we will deliver it in 2 months”. And both the teamlead and the team manager were only hired 2 months ago. Their predecessors had left the building. Needless to say I turned down this “amazing” offer much to the surprise of the hiring team.

Scrutinize the leader

The leaders of a company set the tone for everyone else. Who is a “leader”? It could be the CEO, the founder or even your manager. Have a good look at these people. They determine the ethos and care-factor of everyone around you.

An example is where I was interviewed by a CEO of a small IT Services’ Company. He referred to his technical resources as “Nerds” and went on to say that he didn’t know anything about Computers. He was also proud to say “We are not Google. We don’t want to be anything like Google” and “We build Software. We are not building Rocket ships to the moon!”. I should have run to the door and never looked back. Instead I proved to myself over the next few months that I should have indeed made that sprint when I could.

Here’s what I should have learned from the above interview:

  1. When CEO stated that he didn’t know anything about Computers, he admitted that he knew nothing about the industry in which his Company was operating! Why was he running an IT company?

  2. By calling people who understood his business “Nerds” he was happy to distance himself from the actual employees doing the work that made his Company money. He was also happy to be derogatory to a potential new hire and thought nothing of it.

  3. He obviously didn’t understand the complexities of Software. He assumed developing Software was easy. No big deal. Anyone who has worked in Software for more than 2 minutes knows different.

It’s hard to escape from this kind of cluelessness. The CEO’s attitude directly affects higher management. He continues to hire clueless people to run his project teams and they in turn hire clueless people to manage you and your team! Talk about a vicious cycle. When it all goes to pot (and it will) the “Nerds” aka you and I, get the blame. Needless to say the project I was on was in dire straits.

Standup for yourself

We’ve all worked at a Company where they want you to “hit the ground running”. A friend of mine joined the Company I was working at. He was tasked with taking over the work of an experienced programmer who have been working on some secret squirrel project for the last few months. “Don’t waste your time writing any tests” he had been told. He was a contractor. The Company had mishandled his contract and he had rightly found greener pastures. My friend was tasked with delivering the contractor’s work in 3 days. He didn’t have his computer set up. He had just walked in the door and he was already on a suicide mission.

My friend rightly said “No. I can’t do it. I don’t have the domain knowledge to get this done in 3 days”. Pretty obvious and he didn’t even have a working machine! He was met with resistance from the project manager. “Why not try?”. But my friend rightly stuck to his guns and said “No. I can’t do it. Get someone more experienced with the System to do it”. After quite a lot of deliberating the project manager reluctantly agreed to shelve the changes and give it to someone else. “Wow!” I thought. It was refreshing to see someone standup for themselves. I myself might have “tried”. I would have tried to get everything working as fast as possible. I would have had to cut corners. I would have worked late. Most heinously, I would have reinforced the fact that giving developers unachievable, impossible tasks was okay.

At another workplace I was repeatedly asked to work the whole weekend. The request came at 4pm on a Friday arvo just as I was leaving the building. I gave a polite “Sorry! Had you only told me earlier. I have plans” and walked off. The next week, the same thing happens. Around 4pm the same question. The same answer. It really didn’t stop them asking and it didn’t stop me giving them a flat “No”. Had I been asked earlier I would have at least considered working the weekend.

It’s all about respect. Obviously someone thinks it’s fine to ask employees to sacrifice their entire weekend at the very last moment - for cash. Like people can be bought and used at will. This also goes to show the great planning around this project.

Rarely have I seen any developers standing up for themselves. We need to do it more and not accept the unrealistic expectations and pressure put on us. We need to be more professional. The more we do this, the better it is for us as a group of professionals.

Keep away from unethical people

Some Companies are happy to take large sums of their Customers’ money and return utter crap in return. Testing is overlooked, shortcuts are taken. Everything is held together by ribbons. At one Company I worked at they were using their Customer as “first-level testing”. Hilarious! This too after charging them a lot of money for the privilege of using their crappy excuse for a product.

If a Company doesn’t care about its Customers who give them loads of money, the chances of them caring about you, a lowly developer, are pretty close to zero. You are just someone else to be exploited. They think getting paid for delivering rubbish Software is okay. No moral issues there. Your cheese has been moved.

##Use short contracts/probation to your advantage

Contractors are always after long contracts. Permies are always trying to signup for a lifetime at a Company. I think this is all backwards. When contracting I would prefer a weekly contract. Let me tell you why. If the company I’m working at turns out to be a stinking hellhole (and some of them do) the fact that I am only a week-away from getting outa there fills me with hope. Imagine walking into a nightmare workplace and being stuck there for 6 months! Worse - a year! Oh the horror! No amount of money is worth working at some Companies.

One Company I worked at seemed quite normal when I started but a few days into it, it turned out that employees of the Company thought that swearing at each other across the room, daily, was an acceptable way to behave. There were 3 developers always going at it. They were called “The Triangle of Anger”. Oh dear! Also it turned out that the management hated the developers and the developers hated the management. With this blood-feud going on I was put on a “mission critical project” by myself and was managed by 5 people - each telling me something different to do! People were leaving the Company left-right-and-centre. There were talks about firing everyone and outsourcing it to another Company. Morale was pretty high as you can imagine! Oh the fun! :)

The same goes for probationary periods for permies. For the first time ever I refused to sign my post-probationary documents. If you find a Company less than optimal to work for during your probation, it’s quite likely it’s only going to get worse once you sign up fulltime. Here’s why: Once you are post-probation, you usually have to give the Company 4 weeks’ notice. Try finding another job where they are willing to wait 4 weeks until you finish up at your Company. It’s really quite hard. Most jobs need to be filled in under a month. Most of them in 2 weeks. This is just the way Companies seem to work in Brisbane. They only look for developers at the very moment that they need them. Not a (few) month(s) before.

If you are not sure about a Company, start looking for work a month before your probation runs out. That way you usually only need to give a weeks’ notice before you head off.

Beware of Amatures

We are all Amatures in one way or another. What I mean by that is that we all have things we don’t know. There are always people who know more about something than we do. The features of who I consider to be an “Amature” are given below:

  1. Refuses to write tests because “there is no time”.
  2. Hasn’t learned a single new API or language or framework or tool since 2004.
  3. Is literally scared to upgrade libraries as it may “break something”. “I can’t move to Junit4, as the world will implode”.
  4. Doesn’t understand generics. “I like a List that can hold anything. It’s more flexible.”
  5. Prefers XML over annotations because they are more “readable”.
  6. Thinks that writing Class names into a database table is “all good”.
  7. Writes 1000 line classes and says “It’s good because all the code I need is in one place”.
  8. Hates TDD because “There is no way you can write tests before you write code”.
  9. Hates pair programming because it is a “waste of time”.
  10. Thinks writing hard-to-understand-idiotic-code is macho.
  11. Doesn’t know the difference between a Unit test and an Integration test.
  12. Thinks test isolation is “optional”.
  13. Doesn’t know how to use their IDE.
  14. Thinks there is nothing wrong with a 6-hour build.
  15. Is afraid of using mocks as “they are too hard to understand”.
  16. Refuses to use code style such as checkstyle on the source.
  17. Refuses to run tests before checking in their code and thereby breaking the build.
  18. Thinks that taking 5 days to write 600 lines of mock code to test a Class is fine.

I don’t have a problem with people who have the qualities listed above. I do have a problem with people who have the qualities above and who refuse to change. What this means is that it is now 10x harder for you to do a good job as you have constantly fight these “Amatures”. They will waste your time and drag you down. Unless you can make a change for the better with these guys there is absolutely no reason to keep working in that same team. Leave while you still can!

The myth of Agile

I’m totally over every single Company I work for claiming to be “Agile”. It’s just another buzz word to them. “Oh yes! We are Agile! We have x week iterations”. What they mean by Agile is:

  1. The Software is evaluated at fixed time frame. Usually 2 weeks to a month. (So far so good)
  2. The business gets to change their mind every single day. No re-evaluation of the story cards is done.
  3. The developers are never consulted for estimation of the story cards or an architect-type is consulted to give estimates for each card (fairly useful since he doesn’t implement a single card!)
  4. The business expects all their updated changes at the end of the iteration. No excuses! We are “Agile”.
  5. Testing is optional.
  6. There is no acceptance criteria on the story cards - which is good since nothing is accepted!

Most of the time there are no story cards. Just vague requirements that change on a daily basis. When retrospectives are done, all the ideas are just written down and improvements never get implemented. Each retro turns into ground hog day with most people just falling asleep.

Iteration opens follow a similar path with too much work assigned in each iteration as they did the iterations before. The lights are on but nobody’s home.

Some have requirements’ documents that they’ve been working on for 6 months! Waterfall anyone? But no. They are “Agile”. They know what they are doing. As the projects start to fail they blame the developers and the “Agile” process.

This is such a scam that I am going to ask people real questions about their processes to figure out whether they actually know anything about being “Agile”. Don’t be fooled by Companies being “Agile”. Most aren’t. If you are not sure ask them some pointed questions.

Foster good habits

We are all creatures of habit. If you get used to not writing tests then you start to think that not testing your code is fine. If you get used to working in a waterfall methodology, you see nothing wrong with long feedback times and reams of documentation. If get used to tip-toeing around broken builds/tests/deployments then you will think automation is too hard. In everything you do try and do the best job you can.

Some habits to foster:

  1. Always write tests for the code you are producing - preferably TDD. If there are no tests - write the tests first then start on your work.
  2. If the build is not automated then automate it. It will save the team hours of pain immediately.
  3. If there aren’t story cards/requirements - do not start work. Write the story cards and acceptance criteria and then estimate it. If you can’t do it, get someone with the knowledge to do it. Then start work.
  4. If you see quicksand code (code that sucks you in and threatens your life) refactor it! It will not only make the code cleaner but it will increase your understanding of the system. See 1.
  5. Don’t write an integration test for a piece of code that can be tested thoroughly at the unit level.
  6. Run code coverage on any code you write - even if the rest of the team isn’t.
  7. Run checkstyle or a similar tool to ensure consistent formatting.
  8. Write many cohesive small classes. Do this specially if all the other classes are 1000s of lines long.
  9. Say “NO” to unrealistic deadlines, features and requests.
  10. Where possible try to introduce better processes where you see better alternatives.
  11. Check in often - more than a couple of times a day.

Even if the organization you are in is not working in a professional way, that’s no excuse for you not to.

As developers we need to have a baseline environment before we start writing code. If this baseline does not exist then our first priority should be to establish this baseline - with approval of course. We should not start work no matter how much of a hurry the Customer is in, if this baseline environment does not exist. This is the bare minimum we need to do a professional job. An example would be having a stable development environment, version control, automating the build, having a CI server, etc. First things first.

Know when to leave

I think we all know whether a Company is good to work at, in under a week. Sometimes you want to give the Company a chance to make improvements. “We are not perfect” they might say. Fair enough. But set a deadline for when some of the improvements should happen by. Most of the time none of the changes proposed are implemented. This might be your signal to leave.

Sometimes it’s an external event that signals you to leave. It could be the way the Company treats a certain employee. It could be the way they treat their Customer. It could be the way they treat you. You might notice quite a few people resigning every week (they might know something you don’t). It might just be that you have nothing left to learn in the Company and everyday you stay there you lose a little more skill - a little more enthusiasm.

In a Company I worked at a number of years ago, I specifically mentioned that I didn’t want to do any form of teamleadership. I wanted to be a developer and that was it. Everyone nodded at the time. Just after my probation had ended, I was thrust into a teamlead position I did not want. There was no choice about it! The eventual result was that I resigned at the end of that project. I didn’t want to work for Company where people didn’t understand boundaries or English.

At a more recent job, a group of us were coming up with changes to make the broken development processes better. We wanted to ensure the project made it over the line and the customer got a decent product. The outcome was a disciplinary email from the then manager warning each of use to “Stop wasting time” and to “get back to work”. He didn’t care if the project made or not. All he cared about was how it looked. Us coming up with heaps of changes meant that he looked bad and he had to put a stop to that. The unfortunate thing was that this “shutup and work” attitude was supported by upper management. The last thing I wanted to do was work at a Company where progress was not valued and where voices where drowned out by clarion call of authority. I resigned the next day.

I hope some of the above anecdotes have resonated with you. I am really shocked at how immature the Software industry really is. Imagine telling a builder that you need a building 3 months early. Or imagine changing your mind about whether you want a one or two story house mid way. It’s not going to happen is it?

We get these kinds of change requests all the time in Software and we are happy to do it. We need to have better boundaries!

I wrote this rant to help me remember what to look out for when applying for new positions. I hope it will give you some insight when you apply for your new position as well.