Mar 05 2019

5 fundamental rules of a career

Category: MiscellaneousIuliana @ 0:56

A while ago I was asked by Apress to write a blog entry for their blog. It took me a while to do it, because I was unsure of the topic. I also had a character limit, so it was a little tricky. Finally after about two months the blog entry was posted on their blog and it looks a little weird. I’ve written it in Google Docs and somehow I managed to screw up the text arrangement. So I decided to post the complete article here, with some additional links and corrections. Enjoy!

I develop most of my solutions using the Java language. I discovered this wonderful language in my second year at the university. At the time IDEs were slow and information was scarce, it was 2002 after all. All I had to learn this programming language was a confusing course that was most likely 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, and the main reason of this was because 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 carrier from it was the fact that my first computer was very slow and 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, of course, to spend four days slimming down a Gentoo installation, then slimming down an Eclipse editor so I could have the IDE running, a browser opened so I could read some online documentation and Winamp. Because music is a good companion when learning new things.

As I mentioned, my entire career is build on the Java language. During the years of my development as a Software Engineer I’ve learned many things, but there are five things that I consider them to be the fundamental bricks my present career is based upon. And I would like to share them with you, because every big things starts small.


Story number one: 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 of the official Java API Documentation. That link has been a constant in my bookmark for more than 10
years now and has been updated as soon as a new Java version was released.

So, rule number 1: Always RTFM, Read The F**ing Manual.


Story number two: 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, 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’ve done written defective code and I was also 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, and it was something related to how the JVM reads files when using class FileInputStream, that I’ve covered in my latest book: Java for Absolute Beginners.

Rule number 2: Ask. People will not know or sometimes will not care that you have a problem. Or maybe they are shy and reluctant to offer help because of it. So, take the first step, ask. In a professional environment – a request for professional help will rarely be refused.


Story number three: At a more recent job, I was still getting familiar with the project, which was huge and it was written by a few 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 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, again 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.

Rule number 3: If you don’t like it, change it. Nothing is perfect in this world, thus code is not either. There is always room for improvement. And this applies to company culture and management too. So do your part: speak up and act. You would be amazed how many things you can change just by getting a little more involved.


Story number four: 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, they have peaks of efficiency moments and bugs. We have cheerful moments and we have low ones. Every experience is a learning experience. From the best professionals, copy behaviours that will make you the best. From the worst you can learn what not to do. From mistakes you can learn what was tried and failed, so you will know what not to try. And yeah, preferably learn from mistakes done by others. And teach others. We all die not knowing a lot of things. But be generous with your knowledge, share it, so we all die knowing more things.

Rule number 4: Acquire and share knowledge. It is beneficial to all of us.


Story number five: We talk about Agile, Scrum, Kanban and a lot of other planning and development methods that were invented to produce the best code and the most stable features. 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, 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 any of them to build a quality product. There is no place for ego, shame and competition within a team, we all have our place, we all have different abilities that should be used to benefit the end result of our collaboration.

Rule number 5: Work with friends, not colleagues.


These are the most important rules which 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 and they are also quite generic, they can be applied to any domain really. You will probably never reach your full potential and 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 as well, because no matter how good you are, you won’t always be able to do the work alone.

I decided to make this entry more 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.

About me

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

Leave a Reply