Category: Careers

To be a professional programmer, there are many things that we have to do to be a good one. In this article, we’ll look at what to do when we’re late, and why we need test-driven development.

Being Late

Most of us will be late for something eventually. We may be late for various reasons, like not getting enough time for estimates. To manage lateness, we should tell everyone that we might be late- we shouldn’t give people hope and then disappoint them.

If we’re going to miss a deadline, then we shouldn’t rely on hope to get it done. Rather, we must have a fallback plan to deal with being behind. If people try to force us to change the estimate, we must stick with our estimate. We just can’t buckle under pressure to try to make the deadline. If we do, the product probably won’t be good and the code is most likely also going to be bad.

It’s impossible to solve problems faster, we get stuck and we probably can’t get faster. Over time this becomes risky. We’ll be tired and burnt out by the end of it if it lasts one. There is just no way to get something done well by rushing it.

Changing the definition of what it means to be “done” also isn’t good. We may want to move on faster by changing the definition of done but it is not good to do that. No one wants to see all the real work that actually isn’t done even if we say it is. The easiest way to define being done is to make sure that automated tests pass.

Helping Each Other

Programming is hard. Therefore, we need all the help that we can get. We can’t just put together some code and hope that it works. Instead, we’ve to design everything into well-organized pieces that don’t depend much on each other as it’s beyond one person’s ability to do it well.

We’ll certainly benefit from another programmer’s help and ideas. This means that we should help each other so that we can make all our lives easier. If they need help, it’s time for us to jump in. We should also accept help from others when we have problems. This way, we also get things done faster and better. Also, we should learn to ask for help- when we’re stuck, it’s time to ask for help.

Mentoring

Less experienced programmers need help from people with more experience as training courses don’t always cut it and sometimes books can’t help that much either. Receiving mentoring from more experienced programmers, on the other hand, can help with that.

Test-Driven Development

Test-driven development can help us a lot with writing code faster and better. We write the tests first and then we write our code. We write code to make the tests pass and then we’re done. First, we write a few tests and then we make them pass. Then we repeat the same thing for the rest of our project or tasks.

We get fewer bugs because we have the tests to catch them. If we have tests, then we wouldn’t worry about making changes because we can clean them up on the spot. The tests will make sure that our code is still good. Clean code is easier to understand, change, and extend. Defects are less likely because we simplified our code.

Documentation

The tests have descriptions to describe what it’s testing. This is a great source of documentation for us. It also shows us how to use some APIs in the code with the test code. The tests call functions, so we know how to use them. And they make requests, so we’ll know how to make requests with them if it’s a web app.

Design

To make code easy to test, we test them in isolation. This means that we have to decouple the code. This is great since we don’t want tightly coupled code. Therefore, writing tests first will help us improve our design. Most of the time, it’s practical to use test-driven development. However, there are some rare times that it’s not the case.

Conclusion

If we’re late for a project, then we should communicate that and stick to our timeline for finishing stuff. Getting and receiving help is also a great thing to do. Writing tests are great since they test our code and also serves as documentation.

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.

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 how to continuously improve ourselves.

Continuous Learning

In the software development world, things change a lot in quick succession.

However, like with anything else, software development is maturing with the accumulation of knowledge.

Many things that need improvement have improved thanks to decades of knowledge accumulation.

Therefore, learning now shouldn’t be hard work.

We can learn from videos, blogs, conferences, forums, books, and more.

The more we learn, the more useful we are.

Practice

Another important thing to do is to practice.

We got to keep our skills sharp and ready.

It’s hard to internalize programming knowledge without practice.

Like with anything else we want to master, we just got to practice it.

There are many things that we can do to practice.

We can do simple programming exercises from LeetCode or Project Euler.

Also, we can build apps and other programs that we want to use.

We can pick some technologies we want to use and write apps with them.

There are lots of things we can do to maintain our skills.

Collaboration

Collaborating with other people is another great way to learn.

We can make a special effort to practice programming with other people.

It’s sometimes more fun than working alone all the time, and we can exchange knowledge easily.

Teaching

Teaching is also a great way to learn.

If we can teach what we learned, then we know we learned it well.

We can bring people into a group and present what we learned.

Professionals take responsibility for learning people less experienced than them.

They won’t let them go unsupervised.

Know Our Domain

We got to understand the domain of the solutions we’re programming.

This means that we got to know the business requirements well.

Otherwise, we probably build things that don’t create the right results for the users.

For instance, if we’re building a payroll system, then we got to know about income taxes and accounting.

We probably want to read some books on these topics.

It’s bad to code from a specification without knowing if they make sense to the business.

We should know enough about the domain to be able to recognize and challenge specification errors.

Identifying with Customers

We got to know what’s bugging our customers.

Otherwise, we build things that they won’t be happy with, and then we got to do it again.

That’s definitely not ideal.

Humility

Programmers should be humble.

Risks are taken in a calculated way based on our confidence.

This means that we should be aware that sometimes we’ll fail.

Risk calculations can be wrong, our abilities may fall short of what’s required.

It means that we should never be arrogant and ridicule others.

Saying No

Sometimes, we just got to say no.

There’s no way that everything can be done nicely and quickly.

Also, there’s no way that many features can be implemented in a short timeline.

It’s just unfortunate that the ideal situation won’t happen.

There are always issues that we run into that slow us down/

Being a Team Player

Team players communicate frequently.

We also keep an eye on our teammates.

It’s not someone that says yes all the time.

People that advocate for the team are team players.

Trying

If we have any reservations about our commitments, then we shouldn’t commit to something 100%.

We can only commit to what we know can be done within our timeline.

There are always issues that we run into when writing software and we’ll disappoint people if we promise too much and deliver something less than that.

If there is any uncertainty, then we should communicate that.

If things are looking better, then we can communicate that.

If something is slowing us down, then we should update people on that.

The Cost of Saying Yes

We can’t always say yes to everything.

If we do, we won’t have time to do everything that’s promised.

This means that we’ll be stressed and we never get enough done.

Also, if we rush, then we make mistakes and we deliver something crappy.

The code that we write also probably won’t be the best quality.

Conclusion

We should think twice before saying yes to everything.

There is no way that we can do everything. Otherwise, we’ll have problems because we rush our work.

Also, we should learn and practice to keep our knowledge up to date.

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 when we should code.

Worry Code

If we feel bad, then we shouldn’t be coding.

Stress distracts us from doing the hard task of coding.

We can’t maintain focus or concentration.

Also, we get tired and we get stuck with problems that we may able to solve faster if we feel good.

We just got to know how to shut down these bad feelings and get on with coding.

Coding is also a good distraction from all the bad things that are happening in life.

We should also find a quiet place to write code if it distracts us.

Flow

Flow is when we’re in a productive state,

Some programmers also call it ‘the zone’.

It’s when we’re in a focused, tunnel-vision state of consciousness that programmers can get into while they write code.

It’s when we’re feeling productivity.

When we’re in the zone, we’ll write more code.

We’ll add more features and refactoring them more quickly.

However, we may lose some of the pictures when we’re in the zone, so we may make decisions that we’ll have to go back later and reverse.

Therefore, we may want to walk away and take a break as we go into the zone.

Pair programming also prevents us from going into the zone.

The zone is an uncommunicative state.

Pairing requires intense and constant communication.

Music

Music may be distracting to us when we go into code.

Therefore, we may want to turn it off when we code.

Not everybody can code well with music on.

So if it distracts us, then we can turn them off.

Interruptions

Another bad thing that happens when we go into the zone is that we get mad when interruptions happen that take us out of the zone.

We may snap at people that take us out of the zone.

However, sometimes we’re stuck on some hard problem that needs concentration.

This may also lead to us being mad at people that interrupt us.

Pairing can help with solving hard problems.

Our pair partner can hold the context of the problem while we deal with the interruption.

When we return to pair programming, then we can reconstruct the context before the interruption.

Test-driven development also helps us with holding context.

The context are in the test. If we have a failing test, then we have a problem.

Writer’s Block

Sometimes we get stuck when we write code.

Often we find other work to do when we’re stuck, we surf the web or check the email for example.

The lack of sleep may slow our brain down so that we get stuck.

Other things like worry, fear, and depressions are also factors.

This is where a pair partner can help again.

They can help get us unstuck in whatever we’re doing.

Creative Input

Reading things also give us some ideas on how to solve our problems.

Creative input gives us the inspiration to make output.

Books, websites, TV, movies, music, etc. all may help.

Debugging

Debugging is definitely part of coding.

It probably takes more time than writing the code.

Debugging is just as expensive as coding time.

With test-driven development, we can spend less time debugging since we can catch them with the tests.

Ideally, we should spend no time debugging, and we should try to reduce it as much as we can.

Pacing Ourselves

Software development isn’t a race.

There will also be things to do and there’s no finish line.

When we’re tired, we can’t solve the problems that we can probably solve quickly if we’re energetic.

When we’re stuck or tired, we should stop for a while.

We should pace ourselves so that we won’t be working when we’re tired.

When we’re driving, we should also disengage from problems at work so we can concentrate.

Taking a shower is a great time to think about problems. Lots of solutions may come to our brains when we’re taking a shower.

Conclusion

We shouldn’t be coding when we’re tired.

Also, pair programming is useful when we need to get back to work faster after interruptions.

Pair partners also help when we’re stuck.

We should also minimize the time we need for debugging.

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 the most basic requirement to be a good programmer, which is being professional.

Being Professional

Being professional is hard. We got to clean up the mess that we leave, and we got to take responsibility for our work.

We got to look out for issues and respond to them.

There are many things that we’ve to look out for.

We can mess up any existing functionality, we can lose any data, and we’ve got to minimize emergencies that may come up.

This way, we can the systems running so that customers can do use the software that we’ve built.

We got to make sure that everything is functioning.

Software is hard to create without bugs, so we got to think and test them out before we work on them.

If there are any imperfections, then they’ve to be fixed.

QA Finds Nothing

The ideal scenario is that QA just finds no issues and we move on.

They are there to catch issues that developers may have missed.

QA will probably find bugs. There are too many cases in any software.

It’s too easy to miss things and hopefully, QA will find those issues before the software is released.

We got to test our stuff to make sure they work.

Ideally, we have comprehensive test coverage so that we don’t have to test ourselves.

To make sure that everything works, we got to test it.

We can design our code so that it’s easy to test. If we do that, then testing wouldn’t be too hard.

Automated QA

Automated QA reduces the burden of manual testing, so we should make sure that we have automated testing.

If we have them, at least we know that we didn’t break anything existing when we worked on the code.

Software Structure

We got to make sure that the software we work on is easy to change.

If we make them hard, then we’ll have problems working on it later.

Too many projects become a mess once people worked on it.

Tasks that used to be quick take longer and longer to complete.

More developers won’t help since the code is so messy that no one can navigate through it.

If they work on it, then it’ll just get messier.

Therefore, we should make sure that our code is flexible and maintainable.

To prove that our software is easy to change, the only way to find out is to make changes to it.

We want changes to be easily made all the time.

Every time we look at a module, we should make small changes to improve its structure.

We keep adjusting the structure to keep it easy to change.

If we have tests, then we shouldn’t be afraid of breaking code.

If we break it, we would know right away.

Tests can be run on a whim so that we can check if we broke anything.

If there are changes we want to make, we wouldn’t be afraid to make them.

Our Career

We should keep learning on and off the job.

Some employers may provide us with resources to learn, but that’s a bonus.

It’s up to us to learn things and keep our knowledge up to date.

We can definitely learn on our free time.

Even a little bit of time each day can add up to a lot.

The spare time is for learning and having fun during the process.

Photo by Anthony DELANOIX on Unsplash

Know Our Field

Technologies, ideas, disciplines, all have to learn.

Everything is moving at a ferocious pace. So we got to incrementally update our knowledge.

A lot is different, but a lot of things stay the same.

Many things like waterfall development have been pushed aside but we can still learn what it is.

There are things that developers should be knowledgable on at the minimum.

They include things like design patterns, design principles, and some development methods like waterfall and agile.

Also, we should know things like test-driven development, object-oriented development, and how to draw designs on UML diagrams and charts.

Conclusion

Developers should know some minimal items.

Also, we should make our code maintainable and flexible.

Testing our code is also important.