- Published on
- Reading time
- 4 min read
Being a Professional Software Engineer
- Authors
- Name
- Anderson Eleutério
- Github
- @Anderson-Andre-P
Introduction
So you want to be a professional and deliver better results? You want to climb to the top of the Empire State Building and tell the world: "I'm an amazing programmer!"?
Fine, no problem, but... be careful what you wish for, it may mean a lot more than you think!
Don't be "The Hero"
Software development is a collaborative task done by a team, and depending entirely on a single person can hurt the project.
Promoting the idea of individual super programmers also ends up devaluing teamwork.
Personally, I believe every developer who wants to be the hero actually wants to boost their own reputation, thinking it makes them "special" or that they'll be praised for it. They won't! What will probably happen is burnout. Whenever there's a problem, who gets called? The Hero! Whenever something breaks, who gets called? The Hero! And if something goes wrong? The Hero gets the blame!
On top of that, while trying to boost their reputation, heroes end up neglecting their responsibilities, and can become a hero in development and a villain in production.
Imagine one of your responsibilities is testing. In your rush to become special, you won't want to test, so you can deliver faster. In the future, that time saved turns into trouble and headaches!
Test, test and test
We know it's practically impossible to build bug-free software, but that doesn't mean you should stop caring about bugs.
In fact, it's precisely because they exist that a professional has the duty to take responsibility for writing the best possible code!
Professionals should test their applications before sending them to QA. QA's job may be to report the bugs they find, but developers' lack of professionalism can delay schedules and reduce trust in the code. Remember that QA runs many kinds of tests (for example, usability and load) and writes a report at the end, and that can even lead to people losing their jobs because of programmers' lack of professionalism.
Tests are still necessary to know whether the work meets the requirements, that is, whether it works as expected.
It's extremely valuable for a team to have 100% coverage with automated unit and integration tests. They run quickly and make future changes and refactoring safe.
Your duty (and personal obligation)
Think about it: if the career is yours, whose responsibility is it? It's certainly not your boss's job to train you... Employers have no obligation to pay for conferences, books and courses (there was a lot of that during the pandemic, when there was plenty of money around; now we're back to reality). These things add to your career and should be your responsibility.
It's great that some companies do this for us, but it's much more a favor than a duty.
It's also not your employer's responsibility to give you the time you need to learn. You should come in already knowing it, or learn outside working hours.
But you'll say: I don't have time! So let's do some math: a week has 168 hours. If you sleep 56 hours and work 40, there are still 72 hours left. Even with a family, I think you could set aside at least 10 hours a week to improve (if you can do more, do more). Those 10 or more hours aren't for your boss, they're for your career and your growth as a professional.
Know your field
Do you know OOP? DSA? Can you implement a priority queue without looking it up? Do you know DDD? Can you write a SQL query? Do you know the implications of Moore's law?
If you don't know the answer to these questions, why not?
Our field has a long history, with a wealth of technical and scientific knowledge that could add a lot to your career.
As Uncle Bob said: "If you want to be a professional, you need to know a considerable slice of your field, and keep growing that slice."
My personal list of minimum requirements every software engineer should be proficient in:
- Programming: Data Structures and Algorithms (DSA), OOP, Test-Driven Development;
- Methodologies: Scrum, XP, Lean and Kanban;
- Artifacts: UML and entity-relationship diagrams.
Uncle Bob's list in the book "The Clean Coder" is worth reading.
Learning through practice
A motto I follow is lifelong learning. I follow it because our industry changes constantly, and seriously, if you go 6 months without studying, a lot may have changed when you come back. Anyone who decides to stop studying will certainly be left behind by the market.
Besides studying a lot, you need to practice what you study and keep sharpening your skills, so they're "ready" when you need them.
Conclusion
This is the first part of what I think a programmer must keep in mind to be a professional. You may not see it the same way, and that's fine, but then don't complain about being easy to replace in the organization you work for.
As a reading suggestion, I recommend the book "The Clean Coder" by Uncle Bob. It's worth it because it shows his view of what is needed, and I based this post partly on the book, in my own words!