Developers need to continue to learn to be competitive especially in computer science since new technology and tool sets are constantly being developed. To help facilitate learning, there should be a culture of learning in the company. If everybody in the company is complacent in just using the same tools or not learn anything new, it does not encourage anybody to go on and learn new stuff.
Learning new ideas lead to try and drive technical changes. This might be simple in a start up company but at older companies, departments and bureaucracy can lead to huge resistance on change. Not only do you have to try and convince your co workers and your boss. Your boss may have to convince your department, your department may need to convince even higher in the company in important issues. Sometimes order comes from higher-up and there is no way to change the opinion of that.
Sometimes companies hire the wrong type of person for their position. It can be hard through phone interview to get a feel about a candidate. Sometimes a person that seems to be knowledgeable can have a bad work ethic or may no mesh with the company well. They might not even have the same goals as the company and may just use this opportunity as a stepping stone.
Hiring the wrong people can lead to bad morale. Struggling to get products out, leading to lower morale, leading to slower dev time. It is a downward spiral. Manager and developer conflict can also be a real issue as both sides can have conflicting interest on what is needed to be done.
Finding a great developer can be a challenge. It can take a long time to find one that’s the right fit for a company. A person can be great at interacting with people but may not have the best coding abilities. A person can also be a coding genius but will mesh with the team leading to a lower productivity than the former prospect. It can be difficult to find the best match for a position especially when many times you need to train the new people to their tool sets.
When you first start out, interviewing feels more like “I don’t care, I just want a job”. As you get more experience, interviews become more about a 2 way process. They confirm your skills and your fit to their team. You ask question about their company and what they want to do. Even new, it is important to try and ask questions about the company.
TDD and agile development is always talked about. Pair programming is always praised. However, sometimes those practices are just not feasible. Many times programmers will have multiple issues/projects they are working at once. Although you might have some time to collaborate with your co workers, chances are they are also busy and you are mostly asking questions instead of pair programming.
Extreme programming seems to work the best in some situations but not all. In extreme programming, the team self organizes around a problem then solves. However, there can be times where nobody wants to work on a mundane issues that can be critical to an operation. The manager then have to assign, and some projects may not work well under extreme programming.
Saying no can be difficult in a professional setting especially if you are new and your boss wants something. Managers that haven’t really programmed will keep trying to push new features or push frivolous features that takes a long time. There were time in my work where managers were pushing for extra features that ended up being not used by the end of the product cycle. Problem with is, unless you have some experience, you probably can’t say no.
This ties into deadlines, saying no can be hard especially if you are new. However, many people expect you to run into issue when you first start up and it does not hurt to ask. It is better to be delayed than write bad codes that will run into issues in the future. Unless it is a crunch time, then you have to get it done.
The author brings up some interesting point in which it takes more than a few developer to have the craftsman model to work. The entire company has to embrace it. It was interesting hearing him talking about how there would be developer swaps between different companies in order to see how another company operates and bring back information where it can help improve one’s own company. This might not be feasible in every situation as many times companies are competing against each other.
The author again tell us that in order to be a software craftsman, you have to be constantly learning. In order to want to constantly learn, of course you have to be passionate about programming. Practicing new problems and figured out how the problem is actually being solved instead of just trying to brute force solving it. Doing personal pet projects to constantly refine and improve old skillsets while also learning new ones.
It is interesting to see how the author view seniority in programming. In most places, seniority comes with years of experience. One thing that is different in Computer Science than in other field is the constant evolving of the tech, language, framework, and tools. Having years of working in the field and eventually you may become obsolete if you don’t try and constantly learn new stuff. A person that is entry level might know more about the latest node.js technique than a senior developer.
However, seniority does not just mean how well you can program. Seniority can also mean you know how to communicate effectively, how you work well with team, how well you can lead other people. An entry level developer may have better coding skills than a senior developer but I doubt he has other experience that may be critical in a company.