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.

Photo by Maxime on Unsplash

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.

  1. 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.
  2. 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.

Photo by Yasmina H on Unsplash

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.

What Slows Down Software Development

Delays in delivery is so common in the software development world, that it has become a common practice to include a ‘buffer’ time when giving commitments. And the sad thing is, we face delays even after including such a buffer. There are two sides to this problem – either the task has not been sized correctly, or the developers were slow in delivering. I thought of things that causes slow development and could find these major factors slowing down development for me –

  1. Starting Without Clarity
  2. Not Asking Questions
  3. Lack of Knowledge and Skills
  4. Not Getting it Right the First Time
  5. Not Considering All Activities
Photo by Braden Collum on Unsplash

Starting Without Clarity

Developers just break out their editors and start coding right away when they get a task. Almost always the task definitions will have gaps in them. It was probably written by a product manager or a technical architect. Only the developer will be aware of all the little questions that will arise while carrying out the task. So after taking a look at this task, ask questions that help you clear out any vagueness about the task.

Questions like ‘What errors must be returned?’, ‘Are there specific expectations on code quality?’, ‘Does the architect prefer using a certain design pattern?’, ‘Has the task considered its side effects?’ and so on, must be thought of by the developer when they start. Simply put, start with a clear end in sight.

Another thing that helps to achieve this, is to do test-driven development (TDD), where your tester first writes tests that are supposed to pass after the task is done. When you have actual tests, you have so much clarity on what needs to be done and can minimise the number of doubts that will rise later.

Not Asking Questions

There seems to be a lot of hesitation in today’s developers to ask questions. It mainly comes from either being an introvert, or by the doubt that your question might be stupid. Remember – Asking questions doesn’t make us stupid – making assumptions does.

And it also has a spiralling effect. The first time you might feel a little stupid to ask a question and carry on with your own assumptions, ignoring the fact that you are creating a gap in your own understanding. As time goes on and you avoid asking for clarity more and more, the gap keeps widening. At one point, you just can’t bring yourself to take a step back and ask your question for the fear of coming across as ignorant.

Stop worrying that your question might make you look less intelligent, or that you might be disturbing people if you raise questions. Software development is a lot about collaboration. People who don’t collaborate inevitably end up failing in their job.

Lack of Knowledge and Skills

As bitter as this factor may be, it is definitely a fact that lack of knowledge and skills in the developer is one of the top causes of slow delivery. There doesn’t even seem to be a motivation to learn for many developers. Even if the developer is dropped into a project where a new skills are required, often they don’t sit down and learn those skills.

Thanks to the wealth of snippets and quick-fixes available on Google and StackOverflow, it’s very easy to become a copy-paste developer. Just learn the basics of your programming language, and then use the internet for anything that’s required right? – Wrong. Even if every solution you find on the internet is suitable for you and you can finish most of your tasks by searching for answers on the internet, it’s going to make you a slow developer. A terribly slow developer.

You need to be able to do most of your work by yourself without searching for answers. The internet helps in situations when you are stuck. But if you need to search for almost everything you are doing, it means you are stuck all the time. It’s like repeatedly stopping to tie your laces while you are running a race. You will eventually finish, but your progress will be slow and rocky.

Invest time and effort to actually learn the tools you are using. Your language, the core libraries and frameworks you use, your IDE, your build system – these are the things that you should sit down and learn. There is a big difference in quality, speed and smoothness when a developer actually knows how to do their task rather than searching on the internet for every basic thing.

Not Getting It Right First Time

When you complete your development and merge it with the main codebase, you should be sure of what you have done. Have you thought about all error scenarios? All possible exceptions? What assumptions have you made? Have you communicated those assumptions and ensured they are correct? Have you thoroughly tested it? (Yes, a developer is supposed to test their development before sending it off to a tester)

Ensure that the tester won’t send it back to you. Or worse, it won’t end up as a user-reported bug. Or even worse, it won’t break the production system.

Making sure that your code doesn’t have mistakes and bugs are very easy when you are still writing it on your computer. Once your code passes on to the next phase, your mistakes become more expensive in terms of time to fix it. Think about finding a typo on your computer before you commit. Versus, the time to deploy it, have the user find the issue, reporting it back, it landing as a bug on your plate, then you fix and deploy again. Carefulness on your part would have saved that much time.

Time for doing bug fixes is usually not planned into project timelines. So whenever you introduce a bug and it has to be fixed later, it will take away time from something else. Imagine you are already assigned a task and suddenly a critical bug lands on your plate. You spend a couple days fixing the bug, and your original task now has two days lesser to complete.

The timeless proverb ‘a stitch in time, saves nine’ is one of the most important things you should keep in mind. When you work on completing a task, always remember, that you should get it right the first time. Don’t depend on the tester, or the user, to discover a bug. Consider it your responsibility and comb your work thoroughly to ensure you have covered everything – code bugs, user misuse, changes in integrated systems, unit tests, error messages, breaking compatibility – everything. Only then commit.

Not Considering All Activities

When you have a task and a target date, you need to consider what the target date means. Most of the time, when an execution team gets a target date, it means the task is supposed to be completed and available in production on that date. But in developer’s mind, it often gets registered as the date on which they should complete coding. Even when the developer is told specifically that the target date is when the task should be on production, it doesn’t create a concrete realisation in the developer’s mind.

You need to think about –

  1. The time required for your code to be reviewed and merged
  2. The time required for deployment on a QA stack
  3. The time required for the tester to run tests
  4. The time required for the tester to write new tests for your code
  5. The time required for you to fix any errors discovered by the tester
  6. The time required for your code to go to a pre-production environment
  7. The time you need to wait (for safety) on the pre-production environment before going to production
  8. The time required for documentation changes
  9. The time you need to deploy on production

Those are just a few things that come to my mind. You might have more than that (or less), but the takeaway is that you must think about how many things need to be done to call your task ‘completed’. You might think there is a lot of time for you to finish your task, but it’s simply wrong to take all the time to write your code and your tester gets two hours to test before it gets deployed to production. For example, when I get 10 days to complete a task, I usually find that I have 2 – 3 days to finish development and hand over for testing.

Conclusion

Of course those are just a measly 5 factors among several others that contribute to delays in software development, but in my experience, when intentions are good and the project is still delayed, those are usually the main culprits. More importantly, as a developer, those are the 5 points that are actually in your control. Fix them and you’ll stand apart from mediocrity. Be awesome.