To be a professional programmer, there’re many things that we’ve to do to be a good one.
In this article, we’ll look at why we should practice so we can get better, and why we should automate acceptance testing.
Practicing
To learn any skill, we practice.
Programmers don’t practice a lot outside of work.
Some things have changed a lot. Now our computers are much better. Now we can do more faster.
We don’t have to wait for programs to compile today.
Therefore, we can just write programs and test them all the time.
Since we don’t have to wait for days or hours for programs to compile, we can write programs at any time for practice.
To do something fast, we have to practice. We got to write code to practice things that haven’t been done before.
Once we learned by practicing, we’ll gain muscle memory and we don’t have to look anything up to know what to type in.
In programming, we’ve to write in some code to make the program what we want them to be.
To get to that point, we have to practice solving problems.
Once we write enough programs, we can write something t at we want without much trouble.
Broadening Experiences
We can practice programming in many ways. Work is probably not enough since there’s a lack of diversity in what w work on.
If we don’t broaden our experiences, then we’re confined to what we do at work.
Employers want a consistent set of languages, platforms, and domains in which programmers must work.
This means that the technologies we’re exposed to are limited.
There are a few ways that we can practice.
Open Source
We can stay ahead of the curve by joining open source projects.
We can contribute to projects that use technologies that we don’t have exposure to.
For instance, if we use C# regularly, then we may want to work on some Ruby project for example.
Practice Ethics
We should practice in our own time. This way, we keep our time at work to do work-related things.
However, we can practice during breaks as well.
Testing
Testing is part of the job of programmers.
We got to know the requirements clearly before we can write software and test it.
Communication of requirements also has errors and we can never build what people expect the first time when we build it.
Getting Requirements
Getting requirements is always hard.
There are somethings that we shouldn’t do when we’re getting requirements.
We shouldn’t get too precise too early since things often change in the middle of the project.
Things can be different when we work on it now than some time later.
There is uncertainty in any project. Once we built something, then people may come up with different ideas for changes.
This is why we don’t want to make requirements too precise at the beginning since they’re going to change anyway.
Estimation
Estimation is always something we have a problem with.
There’s no point in being too precise with estimates since they are estimates.
They are never exactly correct.
Estimates should be made on low precision requirements. Uncertainty will also throw estimates off.
This is another reason not to be too precise at the beginning.
There are always disagreements and changes.
Acceptance Tests
Acceptance tests are some tests to check if something is good enough for release.
The thing we have to do is to define the definition of done.
When we say we’re done it means that code is written, testing passed, and stakeholders accepted.
To get to that, we need automated tests, and stakeholders can look over them later.
Communication
We got to communicate clearly. Acceptance tests can help us do that.
When we agree to the tests, we agree with what the behavior should be.
We can make it their responsibility to work with stakeholders and testers to ensure that all parties know what we’ll build.
Automation
To reduce the burden of testing, we should automate our tests.
Manually testing all the test cases is too slow and costly.
Automating the tests will make testing a lot faster and we can do them without looking at our program.
Conclusion
Practicing is an important part of improving ourselves as a programmer.
Also, we shouldn’t be too precise at the beginning with our acceptance requirements.
And we should automate acceptance tests to reduce the burden of testing.
