The question of “What makes someone a senior level software engineer?” is one that I have been pondering for a while. Whatever the answer was a year ago, it is different now. These are my thoughts today, based on my experience using AI and from what I can gleam from others.
AI Literacy
This should be obvious. The ability to use AI effectively to do things like evaluate requirements, scope work, write code and create tests cases is a requirement.
Application Architecture
AI is very good at coding. It is not yet as good at application architecture. A main criterion for a well-structured application is that it is easy to maintain. A well-structured application is not just easier for a human to understand and modify; it is easier for AI also. There is a lot of bad code and poorly constructed applications in the world. I would say more bad than good because all of us have written bad code at some point but not everyone progresses. AI does not appear to know the difference between good and bad.
Broad Experience
Now more than ever broad experience is more important than deep experience. The different technology ecosystems tend to become echo chambers where each has a single blueprint for how applications ought to be structured based on the type off applications that were historically built using those tools, and AI is likely to follow that. But there is no architecture, structure, tool that is best for every situation. Engineers with exposure to more ecosystems are much more aware of the alternatives.
Problem Solving
Ultimately the purpose of of software engineering is problem solving. It may be a bug in existing code. I may be finding a solution to a business process problem that would be both effective, usable and likely to be adopted. It may be how to provide a strategic advantage for a business. Sometimes the problems are complicated, and the solutions are not obvious. AI can often suggest solutions, but even those cases, we need to be able to evaluate whether it is the best solution.
Strategic Thinking
It is still an important part of the role to deliver high-impact outcomes by evaluating cost vs benefit in everything that we do. We still need to evaluate risk. We still need to be proactive.
Data Modeling
AI is probably going to be creating our data models at least in some cases. But we still need to be able to review the models to verify that they are correct. AI can easily misunderstand requirements, and these misunderstandings will often show up in the data model. Applications that are built on top of a flawed data model are difficult to fix particularly if they are in production. Do organizations with multiple locations? Will we allow multiple admin users per account? How are privileges assigned? Do we need to track batches or lots for our inventory in case of a recall? Do we need recurring payments? Do we allow multiple email addresses? These all impact the data model.
Security Best Practices
Particularly if in high security fields like health care, financial or national security, I don’t think anyone has confidence that AI will consistently implement adequately secure solutions. The consequences are just too big.
Those are my thoughts today. In six months I may have a different answer. I am interested in hearing yours.
I have never claimed to be a great manager, but I do learn from my mistakes. Every time an employee leaves they take important knowledge with them, and getting stuck in the constant hiring/training cycle is time consuming and expensive. The good news is even if you can't afford to pay top salaries there are strategies that you can use to retain your staff.
Have a mission
A mission is the difference between being a boss and being a leader. Employees quit but followers stay. The mission has to be YOUR mission. There is energy around someone on a mission that cannot be faked. story: I once started a business just because there were people who needed a job
Be a Mentor
Starting to mentor is as simple as finding out what someone's aspirations are and help them achieve them. Every employee worth having wants a mentor. The area that you mentor them does not have to be confined to professional mentoring. It could be spiritual, fitness, parenting, anything. People are loyal to their mentor. I have about a half dozen ex-employees that I mentored who still talk to me regularly.
I have been too quick to fire employees in the past. If someone is struggling find out why. Sometimes if you know the reason you can help them resolve it.
Build loyalty
You earn loyalty from caring and sacrifice - going beyond what is expected. This is easy when expectations are low but a little harder when expectations are higher. Loyalty is built by helping someone out of a jam. This is tricky because your employees usually don't want to tell you when they are in a jam but they will tell someone. The best place to start is to never throw an employee under the bus. If you notice someone strggling find out why and then help them to move past whatever the issue is.
Be inclusive
Inclusion isn't just about race and gender. Make sure everyone is heard, value their opinions - especially junior members. Praise employees who bring up good questions - never punish for a bad questions. Allow employees to question yhour own decisions. None of us are right all of the time.
None of these cost a penny but they will help reduce turnover.
A while back I was involved in a discussion about the qualities of a good leader. Answers like organized, problem solving, adaptability, delegation and an open door policy were mentioned. In my opinion those are qualities of a good manger, but a manager and a leader are different things. A manager is someone people are required to follow. A leader is someone people want to follow.
I don’t claim to be an expert on leadership but here are some things I have gleamed from my personal experience about what a person needs to be a leader.
Vision
Most of us are not naturally charismatic, but you don’t have to be. People will follow someone with a good vision. The business world, and particularly the tech industry, is full of uncharismatic leaders who have large followings because of their vision. To be a leader you need a vision, you need to be fully committed to the vision, and you need to be able to articulate the vision. If your vision excites people they will follow.
Integrity
No one wants to follow or even be around someone without integrity. Integrity is not just about not cheating people. For a person with integrity their words are consistent with their actions. Integrity is being who you say you are and doing what you say you are going to do. You can fake integrity for a while, but history shows that as the number followers grow over time it becomes harder to keep up the charade.
Loyalty
If you want people to be loyal to you then you need to be loyal to them as well. That does not mean you should avoid hard decisions that may be necessary. In a military context leaders sometimes need to send people to their death. But leaders do not throw people under the bus and they do not cheat or abuse their followers. They do what they can to take care of their followers.
Decisiveness
We rarely have all of the information we would like before making a decision. Leaders understand that delaying a decision for long is often no better than making a bad decision. Leaders don’t squander momentum because of the paralysis that results from indecisiveness. Those are my observations. I am curious about your thoughts…
I have head a lot of developers question what they should be looking for when performing a code review. This is a list of things that I think are important.
Do names reflect what things are or what they do? This contributes a great deal to readability and therefore maintainability of code.
Is the code readable? Code always makes sense to the person that wrote it. Are you able to understand the code with the comments that have been provided?
Is the logic correct? Does it accomplish what it needs to? Many bugs occur because the programmer did not understand the requirements. You want to verify that the code does what it is supposed to do, not necessarily what the developer intended it to do.
Is the logic overly complicated? Is there a simpler way to achieve the same thing without sacrificing functionality or performance?
Does the code belong here or somewhere else?
Is the code following good object oriented principles: abstraction, encapsulation, modularity, cohesion (single purpose)?
Is the code reusable? Should it be?
Does the change fit the our overall architecture of the application?
Is the code thread safe?
The git diff is only going to show the lines immediately surrounding the change. Sometimes you need to look at the entire class or module to evaluate the change.
Are there uncaught exceptions. Did the developer assume some cases will never happen?
Are exceptions dealt with appropriately? Are users being appropriately informed?
Are there conditions that have not been accounted for?
External resources like databases have a big impact on the performance of an application.
Does the code use more queries than are necessary?
Are queries returning more data than necessary?
Are transactions implemented correctly?
Does the code introduce security issues?
Are the tests comprehensive?
Is it clear what is being tested and under what conditions?
Do tests comply with your organization's best prqactices?