My 5 Fundamental Rules for a Technical Career

by Iuliana Cosmina

I decided to make this entry about the human side of development work, because the technical side has been quite properly covered in my four books published with Apress so far.

Rule Number 1: Always RTFM (Read The F***ing Manual)

I develop most of my solutions using the Java language. I discovered this wonderful language in my second year at university. At the time, IDEs were slow and information was scarce. It was 2002, after all. All I had to learn this programming language with was a confusing course that was translated (poorly) from the English version of the Java Language Specification to Romanian. It was years until I truly understood how the Java Virtual Machine was actually doing all the magic, as my specialization was Computer Engineering, so the focus was on learning how to use and design algorithms and how to choose the appropriate tools to resolve problems. Of course, I had other options such as .NET, but the deciding factor that made me choose Java and ultimately build a career from it was the fact that my first computer was very slow. The Visual Studio and Windows together ate up all the memory that was available. So, I was basically forced to choose Linux and Java, because it was more practical and affordable to spend four days slimming down a Gentoo installation and an Eclipse editor. This way, I could have the IDE running, a browser open to read some online documentation, and Winamp.

When I got my first NullPointerException, I was stuck on it for two days until a colleague with more experience explained to me what I was doing wrong and gave me the link to the official Java API Documentation . That link has been a constant in my bookmark for more than 10 years now, and is updated as soon as each new Java version is released.

Rule Number 2: Ask

At my first job, the project I was working on was behaving strangely on my computer and I had no idea what was wrong. It couldn't have been something I did - I was barely doing anything, this being my first job and all. It took me two days to tell my team leader about it. I was embarrassed that maybe it was really my fault, that I had written defective code. I was afraid that I would be found unworthy of the job and be fired. I finally told my team leader about the issue, and after a short investigation he found the problem. It was something related to how the JVM reads files when using class FileInputStream, I've covered this in my latest book, Java for Absolute Beginners. People will not always know, or sometimes will not care, that you have a problem. Or, maybe they are shy and reluctant to offer help. So, take the first step: ask. In a professional environment a request for professional help will rarely be refused.

Rule Number 3: If You Don't Like It, Change It

At a more recent job, I was still getting familiar with the project, which was huge and written by very talented and respected developers. Because of that, I was a little reluctant to modify code written by them. But, to be able to develop my solution, it was either that or design the code in such a way that it did not interact with those classes much. I struggled designing an optimal solution for a few days until I just gave up and modified the existing classes. When the code was reviewed by one of those talented developers, it was deemed of good quality and approved for delivery. Nothing is perfect in this world, and thus code is not either. There is always room for improvement. This applies to company culture and management, too. So, do your part: speak up and act. You would be amazed by how many things you can change just by getting a little more involved.

Rule Number 4: Acquire and Share Knowledge

The next two rules cannot be anchored to a certain moment in time. They are lessons learned over time while developing solutions within big companies and big teams. Our brains are very complex organic computers, and they have peaks of efficiency and bugs. Every experience is a learning experience. From the best professionals, copy behaviors that will make you the best. From the worst, you can learn what not to do. Teach others. We all die not knowing a lot of things. Be generous with your knowledge and share it so that we all die knowing more things.

Rule Number 5: Work with Friends

Nevertheless, even if our brains are very complex organic computers, we are humans, not robots. We make mistakes, we change, we have good days, and we have bad days. Know your colleagues. The key to a productive team is to figure out when people are having a bad day and not pushing them and to figure out when they have good ones to challenge them. Also, building trust and friendship with your colleagues leads to a more comfortable working environment, that ultimately does not feel like work. The truth is, for at least eight hours a day we share the same space and breathe the same air with a select group of people. The key to a good collaboration is to know their strengths and weaknesses, and harness them to build a quality product.

These are the most important rules that my career is based on. Of course, there are others - most of them linked to how I develop my technical solutions. But I chose these five to cover in this entry because they are the most important. They also can be applied to any domain, really. You will probably never reach your full potential nor feel truly accomplished in your domain just by excelling at the technical part of it. You need to work on your personal relationship with your team, because no matter how good you are, you will not always be able to do the work alone.

About the Author

Iuliana Cosmina is a passionate software engineer and technical book author, born in Romania. Her passion is producing quality software, that can be satisfactory for developers to work on and for users to work with. Her language of choice is Java and her preferred framework is Spring. She has contributed to the development of different types of enterprise applications such as search engines, ERPs, track and trace and banking. During her career in outsourcing she has been a team leader, acting software architect, and DevOps professional. She likes to share her knowledge and expertise via tutoring, teaching, mentoring and by writing technical books.

This article was contributed by Iuliana Cosmina, author of Java for Absolute Beginners.