There is a difference between professional and unprofessional software engineers.
Professional software engineers don't put their heads down and write the code they are told to write. They do their best actually trying to build good software and once they leave, they leave knowledge behind for others to continue doing so.
A software that solves a problem well and delivers value to the people using it.
Does it deliver value?
Whatever you work on, you should be able to under the question: Does this create user value?
If you can't answer it, you're likely working on something wrong. If you don't have a clue, because you're working on a feature the product team told you to work on, then ask them and hold them accountable: How did you validate that we should work on this? How does it create user value?
No, it is not disrespectful. In fact, you're showing that you care about the company's success. By satisfying and making the customers happy, the company will succeed.
Learning your domain
I don't need to learn the domain or understand our customers, my job is just to write code.
This is wrong. Your job is to solve a problem and build software that delivers value. For that, you need to learn about the domain and your customers.
By doing so, you will be able to contribute far more to the team and company, but not just that, the way you build your software, write your code, will change as you acquire more knowledge about the domain.
Testing is embedded
Let's create a separate task for implementing the test. This way we can implement the feature, ship it right away, and get to the test later.
Tests are not separate tasks. Tests are a part of implementing a feature or fixing a bug. Tests are embedded in the default way you write your code and implement your feature.
Software engineers need to get away from the mindset of tests as something separate, you need it to not just ship the code you wrote with confidence, but to get feedback and verify that the rest of the system works as it should.
A good and important further reading: The purpose of testing.
Improving your craft
Taking ownership and responsibility in your craft. Always learn new things and question the way you do things. There are no silver bullets, and as time pass, we will discover new and better ways of doing things.
Use your time wisely, and find time to constantly learn new things or things to improve whatever you already know. I'm a big believer in habits, they form us.
If you are extremely busy and can't find a single second in your spare time, use your time at work wisely. Form habits at work, they allow you to continuously learn and improve and prevent your growth from stopping.
An idea: Block out 20 minutes every workday just for reading, and try to read at least a book a month. Over 3 years, you will have read 36 books.
The key takeaway is to always improve and learn, and by taking ownership of your craft, you don't find excuses, you find ways to learn and improve!
A great further reading: Software Engineering for busy parents.
Sharing knowledge
Share your knowledge.
By sharing your knowledge, and encouraging your team to do so, the pace of development and shipping can be kept high, not just today, but in the future when you or others leave the team.
It should never feel like: If this person leaves the team, then it will slow our development down. Such engineers are famous for being rockstars. The people who get loads of stuff done, work on the stuff that most of the team finds hard and is a crucial piece of the software's development.
You don't want to be in such situations, and if you are, it is good to get the rockstar to share their knowledge, so you aren't in bad hands once they leave the team.
Foster a culture around learning and sharing your knowledge.
There are multiple ways you can share your knowledge with your team:
- Write articles
- Share articles you have read
- Share YouTube videos
- Start discussions
- Pair program
- Do demos/presentations of what you have worked on or something you learned
- Mob program
- Share mistakes you have done and what you learned from them
You can be wrong
You can be wrong. You won't always be right.
When you think you are right, instead think you're wrong. Be humble, listen more and ask before you answer.
Especially as you acquire more knowledge, it is easy to think you are competent. Although, in actuality, the smartest ones are the ones that know they don't know anything.
Keep in mind, whatever you do now that you find amazing, for me i.e. Test-Driven Development, may be seen as something wrong in the future.
Remain humble, keep a beginner's mind, ask a lot of questions and ask before you answer.
Conclusion
Professionalism in software engineering doesn't come as an accident, it is something you have to intentionally and consciously choose to embrace!
