Home > Uncategorized > What developers do

What developers do

I have already worked as a paid Software Developer for three years now. I am neither a complete noob nor a senior developer, whatever that may mean [different people have different ideas of what that is]. However, I want to list here every kind of task I have done as a developer and also what I saw my colleagues do as part of their work. I expect this to help other software developers with less experience to get a clearer idea of what they need to get used to. This will also allow me to consult my memory for what skills I need to improve on.

1. I have written lots of code. Obvious, no?! I introduced new classes, new methods to existing classes, and I also removed code. You do this even if you do not have any experience as a paid developer. Writing code is the least of what developers do, not the most. And it is very irresponsible to behave assuming that writing code is all one needs to do.
2. I have read lots of code. I have read code that other people have written so that I can determine what part to change so that I can best implement a bug fix or a new feature. Reading code that you are not familiar with is a very difficult task. It can push one’s patience to the limit. It is always best to ask someone that is familiar with the code to help you understand the code that is new to you and is not easy to understand. One time when I was talking to a friend who was invited to join a start-up cited “getting familiar with a new code base” as the reason he was reluctant to join. It is that important to get ready for this.
3. I wrote unit tests. For the less experienced, this is a better way to do that which you do by writing a main method in Java to try your code. However, in the industry, instead of using main methods, we use unit tests. This has the extra benefit because your unit test code documents what your actual code is supposed to do. And, as long as your tests pass, you do have some confidence that the actual code is all fine and no one changed it. At the least, writing unit tests means that there has been more cognitive effort put to understand and write the code. Some people make really good cases of why unit tests are good, and I am a fan of unit testing. But, there is the possibility that someone did change the code, they also changed the unit tests to adjust to the new code, and effectively may be hiding bugs. This may lead to the question: do we need extra unit tests to test the unit tests that test the actual code? But that is a mean discussion. At some point, we need to trust each other’s ability to make the right calls, and with unit tests in place, this point is closer to what a balanced level of trust-skepticism is.
4. I used lots of tools. I have used programming languages, application frameworks, integrated development environments, build tools, source code version control tools, stubs (like fake email servers), Linux tools like grep, pagers, and navigation, code review tools, continuous integration tools, issue tracking, and perhaps more. Now, Java has around 50 key words. It is not too difficult to memorize the keywords, but there are subtleties to some of the keywords and significant consequences to using them. One can never be sure that they know their language. It takes time and experience. But I cannot stress enough the importance of knowing your tools, especially your IDE. I do not have hard data, but I think that most of a developers cognitive workload is done staring at the IDE. And if you are capable of using your IDE’s shortcuts, you can afford more cognitive resources to your actual tasks. Particularly when you are working on an existing code base that you need to get familiar with, which will also be the more likely case. Also, your ability to use your source code version control tool makes you a better team player. It is not too difficult to learn it and the benefit is significant. Know your tools, know your tools, know your tools. That means you will know your team’s tools and you will be helpful to others, too.
5. I had to debug. Debuggers are very powerful tools. At school, I used System.out.println(); to debug. I did the same in my first job. It led to crazy laughs. But sysouts are not the right way. You will inevitably forget removing the sysouts and it can be irritating for others in your team. Plus, your productivity benefits from your ability to utilize debuggers, which is a huge plus.
6. I talked a lot. I frequently had to express beforehand what I intend to do, some times had been intending to do (say for example when someone was reviewing my code). Your ability to communicate effectively is mandatory. You will often have to visualize your ideas by drawing on a board. Sometimes, you might even need to touch the screen and say “this exact part of the code is where I expect the execution to go through and do so and so” [and then add, “but I do not know why it is going through this other part” 😦 ].
7. I had to listen. Just as I talked, others talked, too, and that means I had to listen. Now, it is your interlocutor’s responsibility to be clear, but, you are better off if you understand even when your interlocutor may be less than clear. If you are well familiar with the business domain of your application and with the code, you are more likely to understand others even when their ability to communicate is less than perfect.
8. I spoke English. It is important to note that of the three years that I worked as a professional Java Developer, for two different employers, the client and management have always been foreigners, so we interacted in English. It is mandatory that one is able to speak English if one is to be able to serve in this industry. The small-market needs are already well met with ready-to-use code bases that need minor tweaking. If you are to serve as a developer, you need to operate in greater markets where automation of non-trivial tasks is the need. That means, you need to be able to serve globally.
9. I had to learn. Learning is part of every one of the points above. I had to learn to code, to use my IDE, to learn the new code, the business domain of the code, to learn English. Technology changes, it is inevitable that you will have to learn. Be ready for this. That means, point 8 is a must because most sources of knowledge in this field are in English.
10. Document. It may not always be your job to maintain documentation, but it is good to do. You might need to document the application’s architecture, sometimes you might need to write a comment for the code, though it is best without it. And sometimes you might need to document the behavior of the application. For example, you might need to describe what parameters some part of your application’s API expects and what the response actually means. Simply, you need to document how to best use your application, whether programatically or manually [I thought “programatically” is an English word, but I am having a spellchecker complaint here].
11. I used database clients. It is a must that you are able to interact with your database outside of your application. Knowing how to use a decent database client is a life savior. And it is not so complicated to use one. This also means that you’d need to be able to write SQL.

There you go! I did not plan it to be eleven points but it turned out that I could recall eleven activities in my job as a Java Developer. And, let me assure you that writing code is not the most of what a developer does.

Categories: Uncategorized
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: