Since having joined Cognizant Softvision as a Front-End Developer, the idea of Continuous Personal Development (CPD) has driven me to always aim for things I can improve upon.
I found great mentors in my Team Lead and Community Lead. Together, year by year, quarter by quarter we define new CPD goals, setting new objectives for my career growth. One of the definitions for CPD is “A personal approach to career advancement focused on continuous feedback” and it’s a great and fast way to become a good specialist in your domain. But is “good” enough for you?
One of my recent CPD goals was to read a book by a renowned professional in our industry, Robert Martin, called The Clean Coder: A Code of Conduct for Professional Programmers. The knowledge I discovered in it was so valuable to me that I decided to create a series of three presentations on the main topics discussed in the book for our knowledge sharing meetings in the Cognizant Softvision Romanian Web Community. Those presentations have been adapted into three articles:
Chapter 1 – Mentorship and professionalism
Chapter 2 – Your team and work ethics
Chapter 3 – Estimates, commitment and the courage to say “no”
This article continues with Chapter 1, as we discuss how we can help each other and what it takes to be a true professional in software development.
Chapter 1: Mentorship and professionalism
Let’s discuss what it means to be a “professional software developer.” While this title comes with a lot of pride, it also comes with new responsibilities and expectations.
- A professional is confident in his or her abilities, and takes bold and calculated risks based on that confidence.
- A professional also knows that there will be times when he or she will fail, their risk calculations will be wrong, their abilities will fall short.
- He or she will not demean another for making a mistake, because they know they may be the next to fail.
Accepting help from colleagues
As software developers, most of the time we work on complex tasks and need all the focus we can muster, but sometimes we can benefit from another point of view, a pair of fresh eyes on a colleague’s solution. A fresh perspective can be a profound catalyst for solving problems. There are a few things to consider regarding help from others:
- No matter how skilled you are, you will certainly benefit from another programmer’s thoughts and ideas.
- It is a violation of professional ethics to sequester yourself in a cubicle or office and refuse the queries of others.
- You can create “availability intervals,” so your colleagues know that between 10AM and noon you’re working on your tasks but they can count on your help between 1PM-2PM.
- When someone offers their assistance, be gracious and allow yourself to be helped
Perhaps one of the most important considerations, however, is that it is unprofessional to remain stuck when help is easily accessible.
You see, programmers can tend to be overly-confident, self-absorbed introverts. We didn’t get into this business because we like people. Yes, this is a stereotype. Yes, it is a generalization with many exceptions. But the reality is that programmers do not tend to be collaborators and yet collaboration is critical to effective programming.
I remember when our HR representative asked me at the interview what I was looking for at this stage of my career. My answer? “I’m looking for a mentor.” I found my mentor here at Cognizant Softvision, a place where people are truly interested in your growth. Soon I, myself, became a mentor for some of our junior colleagues, since there were plenty of opportunities to share my knowledge. Some mentorship lessons:
- The best way to learn is to teach.
- Nothing will drive facts and values into your head faster than having to communicate them to people you are responsible for.
- Professionals take personal responsibility for mentoring juniors.
- Nothing can bring a young software developer to high performance quicker than their own drive and effective mentoring by his or her seniors.
Knowing your domain
In order to deliver the best solution for your clients’ needs you have to understand the domain where your software will be applied.
You don’t have to be a domain expert, but there is a reasonable amount of due diligence that you ought to engage in. Interview your customer and users about the foundation and basics of the domain. Spend some time with the experts, and try to understand their principles and values.
It is the worst kind of unprofessional behavior to simply code from a spec without understanding why that spec makes sense to the business.
Know your field
Here is a small list of the things that every software professional should be conversant with:
- Design patterns and Design principles. You should know the SOLID principles and have a good understanding of the component principles.
- Methods. Understand XP (Extreme Programming), Scrum, Lean, Kanban, Waterfall, Structured Analysis, and Structured Design.
- Disciplines. Practice TDD, Object-Oriented design, Structured Programming, Continuous Integration, and Pair Programming.
- Artifacts. You should know how to use: UML, DFDs, Structure Charts, Petri Nets, State Transition Diagrams and Tables, flow charts, and decision tables.
The frenetic rate of change in our industry means that software developers must continue to learn copious quantities just to keep up.
Answer these simple questions:
- Would you visit a doctor who did not keep current with medical journals?
- Would you hire a tax lawyer who did not keep current with the tax laws and precedents?
Why should employers hire developers who don’t keep current?
- Read books, articles, blogs, tweets. Go to conferences.
- Professional programmers often suffer from a lack of diversity in the kinds of problems that they solve.
- Professional programmers practice on their own time.
- Since your practice time is your own time, you don’t have to use the same languages or platforms that you use with your employer.
- Practicing is what you do when you aren’t getting paid.
- You do it so that you will be paid, and paid well.
You create a solution to a simple problem, being careful to keep the code simple and clean.
As the problem grows in scope and complexity you extend that code base, keeping it as clean as you can.
At some point you realize that you made a wrong design choice when you started, and that your code doesn’t scale well in the direction that the requirements are moving.
Going back will never be easier than it is now. Going back looks expensive because you’ll have to rework the code. Going forward you will drive the system into a hole from which it may never escape. By moving forward you are lying to yourself, lying to your team, lying to your company, and lying to your customers.
Prudence and experience will help you avoid certain blind alleys, but you’ll never avoid them all. So, the real skill you need is to quickly realize when you are in one, and have the courage to back out.
Changes to code
The only way to prove that your software is easy to change is to make easy changes to it. When you find that the changes aren’t as easy as you thought, you refine the design so that the next change is easier.
- You make small, lightweight changes to improve its structure
- Always check in a module cleaner than when you checked it out
- Some random act of kindness to the code whenever you see it
Why don’t you fix bad code when you see it? If you touch it you risk breaking it; and if you break it, it becomes yours. Why are you afraid you’ll break it?
Because you don’t have tests.
These tests are written by programmers, for programmers, in the programming language of the system. They are executed as part of Continuous Integration to ensure that the intent of the programmers’ is upheld.
- Unit tests provide as close to 100% coverage as is practical
- Generally this number should be somewhere in the 90s
- It should be true coverage as opposed to false tests that execute code without asserting its behavior
In the next article in this series, we will cover teamwork, ethics and communication as part of your professional programmer journey.