Thoughts – Code Creek

Developer’s Guide to Becoming a Manager

This article summaries my learning as I got comfortable into a manager’s position from being a developer. About 5 years ago, I switched from one company to my current job, just because they promoted me and made me a manager. I refused, and my then manager gave me a long talk on how I’ll get stagnant and go out of relevance if I continue to stay inside my comfort zone. I listened to him patiently, and then I quit. Now, after 5 years, I realise that I really can’t escape that fact. Except for very few careers, you do have to become a ‘manager’ (at least of sorts). Not because it’s compulsory, but because it makes more sense. After gaining enough experience, it’s simply better economic sense to lead (or train or mentor or manage) other people than contribute as a loner.

Even the senior people who claimed they’ve persisted to a ‘technical role’, are just under an illusion in my opinion. They are managing others one way or another. They just aren’t calling it management. Even hard core solo researchers have ‘research assistants’ – which does make it a management job in one way.

So I did commit to learning to become a manager. Don’t mistake me – I really don’t think it’s necessary for everyone to climb the corporate ladder to become CEO one day. I just think us developers need to step out of the comfort zone and learn to lead a few people because it has tremendous value to be able to do that, and opens doors which we might not even have considered before. This article records some of the things I’ve learnt from experience so far.

Lead the Project

You’re no longer an ‘executor’ who has to complete the tasks assigned to them. Management doesn’t work that way. It’s not another job where you get a to-do list. You need to lead. You need to know your project’s roadmap – even if there is a separate Product Manager or Architect who’s responsible for it. If you don’t know this, approach whoever is responsible and get to know it. Make sure you’re in the know when decisions are taken in the project. That’s what you need to be thinking about – Where is the project going next? Will it get there on time? Does it need to switch tracks? Are the initial assumptions still valid?

Delegate First

When you see a task, don’t think ‘I can just do this myself – it’s just a little thing’. That’s probably the worst and most common mistake new managers make. It’s tempting to believe that in the time it takes to explain to another person, review their work and accept it, we can just do it ourselves. That maybe true, only you have a different job now. Your job is not to finish that task – not anymore. Your job is to get a specific person/team to finish that task. So that’s what you should be focusing on. Get out of your comfort zone and start thinking about how you can get the other person to do it for you.

Start Managing

You might have thought so long that managing is just maintaining the to-do list. But you’re in to find out how demanding it is to maintain a to-do list. As a new manager you probably have only one project/team to manage so you’ll be expected to know the status of every single item in your project. You need to know how many bugs are there. How many of them are critical? What roadmap items are coming up in the near future? How occupied are members in the team? How spirited are they? Is any task running the risk of getting delayed? Can that delay be avoided? If not, who should be notified of the risk?

Consolidate

A developer who know how to write programs, can’t really earn his own living by sitting alone and writing programs. A large company can’t get their requirements met by a single programmer. Now that’s where you come in – the new manager. You take the output of several programmers, and consolidate them into a unit which is useful to the company. Most of the job of a manager is just this – to consolidate individual efforts and pass it on to your customer (or your superior). Other activities of a manager – such as appraising team members, reporting project status etc., are supplementary to that main goal. Although it doesn’t come out that much, it’s the fact – you are there to tie pieces together towards an ulterior goal.

Get Feedback

This is something that we usually learn very late. This communication is important, and might be considered one of the most effective communication that can happen between a manager and their team. You should always be on the lookout for receiving feedback about how well you’re doing as a manager. You can succeed as a manager only if your team is committed to your leadership. But you might not be able to ask for this directly. It will put your team members in an awkward situation if you ask them to rate your performance. What your team thinks of you is as important as what your superiors/customers think of you.

Give Feedback

You should be expressive in appreciating your team member when they do a good job. And you should not hesitate to (politely and discreetly) suggest that they need to improve on something. While for many managers it’s easy to appreciate, they try to avoid criticising. They don’t want to hurt another person’s ego. It is indeed a good motive, but not enough to completely avoid giving negative feedback. Learn to do it in a way that doesn’t hurt their ego. Think how to put it such that they take it in a constructive way. Do not shy away from conflicts – deal with them in a friendly and respectful way. Use your influence, not your authority.

Learn Emotional Intelligence

Even before becoming a manager, you should have put effort in increasing your emotional quotient. I remember it was a buzzword and all the craze at one point in the past, but has been forgotten a bit now – unfairly so. Emotional quotient is considered more important than intelligence quotient. It’s common for technical people to start putting up spreadsheet, project management software and all those kind of things – and they start relying on those things. They assume that if they maintain everything up-to-date in their project management software, things will be running smoothly. This is far from the truth. After so many years in software development, I haven’t come across even one strong example where a ‘management tool’ helped success of a project. It’s about how well you connect with people. How well you can influence them. How well you can understand them.

Conclusion

The biggest change when you become a manager, is this – you need to stop thinking about code, technology and programs and instead, start thinking about your project, your team and your customers (or superiors). Less working with computers and more working with humans. That jump is what I’ve seen new managers struggle with. You need to build up your communication, persuasion and networking skills. Start by getting comfortable talking with your team, and always have your project’s roadmap in mind, and you’ll be on track to become an awesome manager.

How to Not Panic in a Job Interview

One of the nice things about sticking for long periods in the same job, is that you build trust and get picked for interviewing potential new employees. I’ve so far conducted more interviews to pick junior programmers than I care to count. I will never say no to conducting interviews because hiring an employee is synonymous to expanding the company. I believe it’s invaluable contribution to help with screening and selecting the right candidate for your company. That candidate is not only going to contribute a lot of value, but they might also be a superstar factor who propels your company to better heights – and their journey in your company would have started with your interview.

The biggest reason I’ve had to reject candidates, is obviously incompetency – but quite a lot of times, I’ve felt maybe this person is competent, but they’re stressed and aren’t performing at their best. At these times, it’s quite easy for me to direct the conversation and put them at ease, and thus having a positive interview experience. But there are times, when the interviewee just panics. Their mind just shuts down, words just come out without much thought or imagination, and I sense they just want the interview to end. They don’t even care about getting the job anymore.

Before the Interview

Preparing for the interview is such a no-brainer and yet, it’s shocking how many candidates turn up without preparation. They think interview is just a conversation and they can simply answer questions from their memory. Walking in without preparation is the number one reason interviews end in failure. The interviewer has probably sat down and prepared to interview you. It’s not only in your interest, but also a courtesy to them that you spend some time properly preparing before your interview.

1. Revise what you know about your skill

If you are about to interview for a programmer job, it’s very important that you study up on your technologies. Do not skip this part. Even if it’s a technology that you’re currently working on, do a revision and checkout common interview questions on that topic. When I interviewed for my last job, I actually asked them that I need a couple weeks to study up on Java programming. If you have studied well, you will be able to give crisp and confident answers. But if you haven’t, you will be dragging your answers around, trying to shoot all over the place hoping something will match with the interviewers expectation. That never happens though. If you have put something on your resume, make sure you’ve read up on it enough to answer questions about it.

2. Know Thyself

I know questions like ‘tell me about yourself’, ‘where do you see yourself in 5 years’ and so on, seem clichéd. But frankly, what else is an interviewer supposed to ask you? Interview is a situation where you need to be analyzed in a rather short time – often barely enough to know a person. There are tons of lists on the internet about ‘frequently asked interview questions’. Select about ten good questions and prepare answers for them. And surely prepare a good answer for ‘tell me about yourself’ – I have a 2 minute answer and a 10 minute answer. Prepare answers for any areas of concerns you might have – for example a break in your career, or why you got fired that one time, or why you have a low CGPA. If you prepare answers like that, you’ll be able to control the interview – distract them from negativities and guide them towards your strength.

3. Know about the Job and the Company

Another easy – yet often ignored – part of your preparation is to know about the job and company you’re interviewing for. Have you even read the job description? There is vital information in the description – it’s not some rough note put up. The HR and the job’s department works together to properly describe the job and what the interviewers will expect. This job description is a vital tool to help you prepare for the interview. And about the company, you need to know it’s core purpose and mission. The answer to ‘do you know about our company?’ should be ‘I know it does __ and __, but I’d like to know more’.

During the Interview

1. Remember the Interviewer’s Goal

The interviewer’s goal is to hire you. Often we have to interview way more candidates than we’d like. When I start an interview, I hope sincerely that the candidate gets selected and I can move on to other work. But candidates almost never have this realization. They always appear anxious as if I was there to push them out of their limits and reject them. That is far from the truth. I’m sitting there hoping to discover what your strengths are. My managers are probably urging me to hire someone soon. There is a project that’s struggling for the lack of a developer and it will be really great if you get hired. If you kept these facts in your mind, you’d be way more confident in your interview.

2. Keep Moving Forward

You might not have answered the question as well as you liked, but are you going to let that affect your next question? That’s what a lot of people do. They start focusing on a mistake they made and lose focus on what’s happening at present. Even a little stutter or slip of the tongue, derails people. And it’s worsened because it gets accumulated with each question. Doing something wrong in one question makes you lose focus and you make another mistake soon and so on, till the point where you are in full panic, accepted failure and just want the interview to end. Avoid this. Forget that you made a mistake. You don’t have to go back and fix it, or convince the interviewer to forget it. Consciously move on and start your next answer with a fresh and positive mindset.

3. Collect Your Thoughts Before Answering

The pressure to impress the interviewer reflects in the candidate’s behavior. I have no idea why, but people always assume they have to answer fast and quick. It’s not like the interview is a rapid-fire round on a game show. My expectation is almost always the opposite. When I finish stating the question, I always expect the person is going to pause a few seconds to compose their answer before responding. Even if the question is straightforward and you don’t need to recollect anything, it’s still useful to pause and take a breath before you start answering. If you answer in a relaxed pace, you appear confident, and you can keep up your energy for longer.

Still Unsure?

If you’ve taken the points I’ve mentioned and still lack the confidence about attending interviews, then the only thing left is to practice.

You can do mock interviews with other people (friends or paid services). But I find them impractical and a bit dramatic. What I would advice is, to do mock interviews in your head. Just play out your interviews in your mind and observe you from a third-person point of view. Granted, you cannot predict how the interview is actually going to be, or what the interviewer is going to ask you. But picturing your behavior makes you less concious and removes one main source of anxiety during interviews.
Consider each interview as practice. Keep attending interviews of similar jobs or similar companies. For the first few, don’t keep expectations of getting hired and keep in mind you are doing it only for practice. You’ll improve with each one. You will automatically get better anyways, but also retrospect and find out how you can improve yourself for your next interview performance. Sometimes the only way you can learn is by jumping right in.

SPA or Not

The latter half of the last decade can be considered an explosion of SPAs. With introduction of Angular 2, ReactJS, Vue and a ton of such frameworks, creating highly interactive web pages became very easy. So easy that competing technologies like Java applets and Flash are being pushed into extinction.

Of course whenever a new UI technology comes in, it’s going to look exciting, have a big bunch of people jumping on the bandwagon, some realise that it’s actually not relevant to them, others realise something newer has come, then finally, most of them move on. But this time, a new ‘concept’ was spun out. The concept of SPAs.

What are SPAs?

SPAs or Single Page Applications are a concept, where your whole website is just one HTML page. Pieces of content inside the page get dynamically modified and updated using content from the server. For example, a single page that has a menu at the top and an empty box at the bottom – when you click on a menu item, the page will fetch the respective data from the server and populate the empty box. When you click another menu item, it will fetch different content, and replace the content of the (initially) empty box.

In contrast, traditional web applications are made of several pages. So the above example in traditional style would be each menu item would be a a link to the corresponding web page. Clicking on a menu item would just order the web browser to load a new page entirely. The disadvantage being, it’s a bit slower to load an entire webpage rather than populating just data into an existing container.

How to Decide?

SPAs are not an improvement on the web UI, and as such, it’s incorrect to assume that ‘modern’ websites are SPAs. SPAs are just a different way to make websites. So it’s important to choose whether or not to use them. This has become an important decision to make because there are significant differences in user experience between SPAs and traditional applications. So much so, that choosing the wrong type can either make or break the success of your web application.

When to Prefer an SPA

When you’re making an interactive user interface, where there is communication between the different components of the page, it’s better to do an SPA. For example, a dashboard that shows data as tables and charts. You probably would like if the charts are all interactive and respond to different clicks on the page – like if you click on a geography, all the charts get redrawn to show data only for that geography. Another example is a drawing application – a large canvas in the centre and a set of tools like pencil, eraser, shapes etc in a toolbar. These kinds of applications are even possible only because of the advances in UI frameworks and SPAs.

When to Prefer a Traditional Website

When your audience is going to consume information rather than interact with it, then it’s better to do a traditional website. Think of blogs, news websites, video streaming sites, forums – the bulk of the internet. It is unnecessary complication to do an SPA if the interactivity it brings is not utilised. Because it’s way more complex to develop SPAs than normal web pages. There are more possibility of bugs and weird behaviour. More importantly, you page is going to be unnecessarily large and slow to download – SPA frameworks are usually heavy.

Also, if you are making a website where people come to consume information, then you probably depend on search engines to bring you traffic. Well search engines are not very good with SPAs. Chances are that your website won’t even be indexed by search engines, if it’s entirely an SPA.

How to Choose

By now, it should be obvious that there is more chance that you do not need an SPA, because most websites exist for consumption rather than interaction. Most people come to the internet to read, watch or listen. And a smaller portion usage is interactive applications like posting blog entries, working with documents, editing images and so on. So the choice is simple. If your website is more for reading, watching or listening, then do a traditional site. If your website is more for interacting – filtering, sorting, drill-downs, slice-n-dice, drawing and so on, do an SPA.

How About Both?

The thing is most of the times, your website might have to do both. Think of a shopping website. The shoppers all have to read the pages, look at the product details, read reviews – so it seems like a site where people primarily read information. But, it also has to be interactive -filtering products, sorting search results and so on. What to pick in this case?

Such websites can benefit from both approaches. So I would use a combination of both. Start out with a normal traditional website. Then introduce SPA features into the pages where it’s necessary. So your website would be like a collection of pages, some of which are mini SPAs. For example, the search results page is a normal page without SPA functionalities. But to improve user experience, the product page might have features like commenting, reviewing, browse multiple product images, buttons to add/remove the product from the shopping cart etc. These can be done SPA-style, so that the user won’t be navigating away from the page to do these little actions.

Still Doubtful?

When in doubt, do a traditional website. It’s easy to get a normal website right. But getting SPAs right is hard work. Wait for circumstances to strongly push you towards SPAs – and then you can refactor your website to be an SPA. Because often when the developers are in doubt, it means there’s not much benefit in increasing complexity. Presenting an SPA when there is not need for one, will just make the user experience worse. Where the situation doesn’t demand it, SPAs stick out like sores and sometimes even end up irritating the user. So again, if you’re confused, just do a plain old website and live peacefully ever after.

How to Create Work Life Balance

Quite a significant proportion of people struggle with the concept of work-life balance. No question, it’s the buzzword whenever there’s a meeting between HR and the staff. No question, all of us want it. But even so, it’s something that is so elusive to actually achieve.

Know About Parkinson’s Law

Parkinson’s law is that work expands to fill whatever time is available. If you give more time for a task, you are more likely to put more effort into it, which sometimes might not even be necessary. Have you noticed some people wait till the last minute and then quickly churn up something to complete their task? And other people start way early, but still are in the same kind of rush towards the end to complete the task?

That’s parkinson’s law at work. When you have more time, your mind puts more into the task and makes it bigger. When you have only less time, your mind prioritizes the subtasks and gets you to still complete it within that time. How to overcome it? Keep milestones with deadlines. What will you complete before 1 o clock? What will you complete before 3 o clock? What will you complete by the close of work? Without doing this, you are prone to subconsiously think there’s time available until late night and complicate your work more or improve it’s quality more than necessary. Surely, quality is important – but remember, you can be indefinitely improving quality of your deliverable.

Do Not Overestimate Yourself

One of the biggest problems when we plan is overestimating ourselves. If you have ever indulged in some retrospection, you’d remember how many times you overestimated yourself while planning. For example, when I was in school, I used to plan that I will study one chapter every hour of the day. I’m quite embarassed to say that this continues even now more that I’d like it to. Last week I planned I will close 8 bugs in my project at work – without even knowing the root cause of those bugs. But it’s okay because I catch myself most of the time – and you should too. Once you overcommit at work, then you will quickly find yourself sacrificing other areas to cope up for it.

It’s always better to undercommit and overdeliver. Ask for more time than you estimated, finish the task diligently, then use the remaining time to polish your code. That’s how you shine. Not by overworking yourself.

Be a Team Player

Are you often thinking it’s better to complete something yourself instead of passing it on to one of your team mates? Especially if you are in a leading position or you are managing a team? If you are not able to delegate tasks and get them completed, it usually means that you are not a good team player. Think and identify why you are unable to delegate tasks to your team mates. Are you having trust issues with your team? Does your team need more training to contribute better? Are you having communication problems – are you simply shy to talk to people?

The biggest strength of corporate structures is working as teams. If you are not taking advantage of it, then you have a serious problem you need to rectify. The typical workaholic mentality is ‘I can just do it myself in the time it takes to explain it to another person’. Wrong. Even if you are a super-skilled master programmer or something like that, it’s highly unlikely that you’re as efficient as a team working together.

Plan Ahead and Stick To It

Plan ahead for your work. I’ve found my sweet spot planning weekly. Some people like to plan more, or less, frequently than that. But you should always plan. Beware of becoming a perfectionist and spending to much time and effort in planning. I say this because that’s the reason a lot of people give up on planning. The planning itself should not become a stressful chore. At the beginning of the week, I like to just quickly chalk up a few tasks that I’d have to see completed in the week. Better if you can do it with your team. I’m not saying you should do the same, but I recommend you do something similar in a frequency that suits you. Right off the bat, it reduces stress by a lot because a lot of surprises get avoided.

More importantly, do as much as possible to avoid taking up unplanned work, once you have done this planning. Although there are genuine chances of unplanned – yet important – work turning up, in my experience, we often accept such work because we hesitate to say no. If you frequently find yourself unable to keep up with what you commit, you should try this – make a light and easy plan, keeping in mind it should be significantly easier than you can handle, and then stick to it. Lean towards sticking to your plan, rather than impressing people by handling unplanned activities. If you are building a reputation, let it be that you respect your time and will not let it be taken for granted.

Create a Life Outside of Work

Many people who struggle to create work life balance, simply don’t have a significant enough life outside work. You might have a family, but if you don’t give it importance, it’s as good as non-existent to you. Similarly you can’t say you have a hobby, if you only indulge in it a couple of times a year. Commit yourself to atleast a couple of things outside of work. For most people one of these things can be your family. Create habits that keep you connected with them. It can be a little habit like, everyday you will have dinner with your family at 7.30 in the evening. Commit to doing activities with your friends.

If you have more things in your life that makes you interesting, your mind won’t have to rely on your work performance to feel good about yourself. You’re less likely to link work to your ego. You’re more likely to plan and organize your day in a healthy way. It is absolutely necessary that you have time for face-to-face interactions with other human beings outside of the scope of your work.

Let Go of Your Ego

The more committed and successful someone get at their job, the more their ego get’s blown up. Soon they find themselves unable to say no, unable to ask for help. Even if they’re obviously overloaded and are struggling to cope up, they don’t reach out and express it. It’s as if they believe people will think less of them if they can’t handle their load. This is people’s ego talking. You need to recognize when your ego is hurting you. The fact is, people who don’t act on time regarding these things, end up hurting themselves more.

Imagine your project is slightly off track, and you hesitate bringing it to attention, because you think it would be perceived as your weakness. A few weeks later, it becomes a more serious problem, and your sense tells it’s better to bring this to people’s attention. But now, it’s harder, because you also have to answer for why you didn’t highlight it earlier. So you will probably try harder to bring the project back on track, without letting people know the seriousness. Avoid this mess by having a clear head, and never ever give in to your vanity at work. It’s okay to reach out and get help when you are overloaded. It’s okay to say the task might take longer than expected.

If you find yourself in a stressful mess, staying back late, day after day. Stop for a moment and ask yourself. What’s the worst that could happen if I tell my manager that i’m struggling and need help? Surely it’s not worse that having an unsatisfying life or spoiling your health.

Conclusion

It’s not very difficult to create a healthy work-life balance that you need to be researching the internet about it. It’s easy. You just need awareness. Stop being a robot and pay attention to what you are doing, what you are feeling, and whether you are happy. Then do something about it.

Are Unit Tests Over-Rated?

Having worked in software development for more than 12 years now, I can safely say that about 20% of the projects I worked on, had unit tests. And none, had unit tests that were actually effective. Yet, I wouldn’t call even one of those applications as poorly written or of low quality. In fact, most of them were quite good – even in terms of maintainability and code quality.

One reason why I think unit test presence was low, is that all software I worked on were customer facing web applications. The emphasis was more on integration tests. I can’t help but think – is it really bad? I think it’s not. While I do recognise a lot of situations in which unit tests might help save the day, I don’t believe in having mandatory requirements of meeting a certain percentage in code coverage. The project I’m working on currently for a multinational corporation, has a 90% code coverage requirement.

Are your unit tests actually testing your code? Or are they just helping you achieve a code coverage metric?

Reasons against Writing Unit Tests

1. Code is not Reused Anyway

In a web application, except for a very little part, methods are always single use. When the code is divided into methods, its mostly for reducing complexity, making it readable and in general having modularity. Think of your typical method – validateTableCreationPayload(), createUser(User user), deleteBook(int bookId) and so on. These methods are going to be used in only one other place in your application right?

It’s quite easy to ensure changing the method doesn’t break the one, single usage of it. And when it does break, almost always, the unit test is what gets rewritten. That’s the thing with application code – you’re not going to deny your client’s requirement just because your unit test fails right? And there is nothing dependent to be changed – remember there’s only one usage. Considering that none of the functionality is breaking – and your integration tests ensure that, unit tests lose much of their worth anyway. And it becomes a ritual to just change the unit test whenever we change code.

2. Sacrificing Development Speed

Unit tests for application code will take as much time developing the actual code. Often, the unit tests take more time to develop than the actual functionality. An architectural purist might not even consider this as an issue. But a business manager will be – Are you saying it actually only needs half the time to develop!?

And unit tests tend to become very complex very fast. In a regular web application, you end up having to mock several components in almost every unit test. As far as I’ve seen, going beyond a certain coverage percentage, makes unit tests unreadable and off-putting to modify.

3. Misleading Sense of Security

You should always do proper diligence before modifying existing functionality. Do not ever rely on unit tests to catch these. Because unit tests are almost always insufficient. Take this example –

public void createUser(User user) {
    addMetaDataToUser(user);
    // new statement inserted here
    repository.createUser(user);
}

@Test
public void createUserShouldCallRepository() {
    createUser(dummyUser);
    verify(mockRepository).createUser(any());   
}

The above test has 100% coverage for the createUser method. But what happens if we insert another statement in the createUser method? The test still would show 100% coverage. The developer who inserts that statement can get away with not even writing unit tests for their change. Such things can only be caught by careful manual review. And unit tests are often ignored when code reviews are done. Especially in teams where an automated process reports code coverage metrics, and (wrongly) says everything is fine.

Worse, the above unit test is inadequate. It only checks if the repository.createUser() method is called. Not that it’s called with the correct argument! If the new inserted statement modifies the user argument, the unit test will still pass, code coverage will still be 100%. Bad, no?

Reasons for Writing Unit Tests

1. Documents Code

If unit tests are well written, they will act as documentation for how and why code is written in a certain way. It’s not uncommon to see a comment in code that says ‘ugly hack .. do not change this’ or something similar to that. The programmer who wrote it understands that someone in future might modify it and the fallout might not be immediate. But this assumes that nobody would have ‘cleaned up’ that comment. Or a future programmer would simply miss reading it. But if there is a unit test that looks out for this situation, that’s a way better safeguard.

Also, well written unit tests have great names that set expectations about the method being tested – shouldThrowExceptionForBadInput(), shouldReturnAValidUuid() etc. Also, these are arranged in neat groups in your test classes. So if your developers follow discipline you can take a look at the unit tests and learn a lot about the code.

2. Protects Sensitive Methods

General purpose methods, which are used all over the application need to be protected from change. For example, if you have a validation method that checks if a string has a particular pattern (maybe your company has a certain pattern for unique IDs), it is very risky if someone modifies this method. Every method you have used twice or more in your application, must have a unit test. The method serves for two tasks. What if you change it for one task and the method no longer works correctly for the second task? Preventing this, is the core purpose of unit tests. Unit tests serve as a guarantee to what the method will do and will not do.

3. Improves Code Quality

In my opinion, this is the number one reason to enforce unit tests. Especially if there are inexperienced developers in your team. If you write bad code, it becomes more difficult to write unit tests. In my initial days as a developer every time I struggled to write a unit tests, it showed me how I could have written my code to be more loosely-coupled, modular and simple.

Your function might have to be broken into pieces, if you are writing too many unit tests for it. Your function is too tightly coupled, if you are writing too many mocks. Are you finding you need to inject ‘private’ dependencies using Reflection? Are you unable to write a unit test because one of your private fields is initialised indirectly (like Spring’s @Value annotation)? Just about every time you find yourself writing unit tests that are too complicated, you can see opportunities to simplify your original code.

Conclusion

Now, if I propose we write only minimum required unit tests, I would be no different from the people who tell me to write the maximum possible unit tests. But one thing is obvious to me, having a code coverage target is pointless. Only the developer who is writing code can decide which part of it has to be registered in unit tests and which parts don’t quite benefit from unit testing. If you don’t give importance to unit tests in code reviews, don’t even bother requiring them – at least your development will be faster and your code base will be cleaner.