Author: John Au-Yeung

It’s easy for developers to make mistakes, but we can prevent them if we know them beforehand.

In this article, we’ll look at mistakes that developers make.

Being a One Trick Pony

Being a one-trick pony if definitely a bad idea. If we only know one thing, then we’re only useful at doing one thing.

That’s just not good since computer and software changes so fast, our skills will be useless in no time.

Therefore, we should learn whatever is popular if we want to continue to work as a developer.

It’s easy to learn new things if we build on our skills.

Trusting Customers to Know What They Want

Not all customers know what they really want. Therefore, we should get more feedback than from a single customer before adding, changing or removing any feature from our product.

Communication is essential to implement a feature that people use. We should also implement it in small pieces and test them with customers along the way so that we can make sure that customers actually like it.

It’s much better than working hard for a long time and having something that no one wants.

Requirements change all the time, so we should prepare for that. Being defensive is no good even though some developers do take that stance. We should help make our products better.

Winging It

We shouldn’t wing it as a developer. That means we should only do things if we know what we’re doing and why we’re doing them.

For instance, we shouldn’t try random things until something works to fix a bug without knowing why we’re trying something. We should know how the code works before trying something.

Also, we should think about all the ways that something can break. This includes edge cases, invalid inputs, bad formatting, etc.

We should have useful unit tests, version control systems, good methodology, and maintainable code.

Unit tests are useful for catching regressions. Version control systems let us revert our code if we messed them up.

A good development methodology will prevent us from doing useless things.

Maintainable code will be easier to change and fix in the future. The code should be built with clear architecture planned before it.

Wrong Person in the Wrong Team

Being in a team that fits us is important. Working in a team that doesn’t fit our skillset or personality is going to be unpleasant.

With respect to skills, we should make sure that we can actually do what’s required in the team so that we can actually produce something.

Also, team fit is also important. Fit reduces conflict and having people with similar personality make other teammates understand us better. This means more empathy.

Frustration, anxiety, and depression may result. This will make anyone’s life miserable. Therefore, we should find a team that fits our skills and personality.

Not Backing Up

Backing up is very important. We should always be prepared to use our backups to recover data.

Cloud systems and our own hardware are all fragile, so we should always be prepared for the worst.

This means having backups in multiple places so that we’ll always have them somewhere.

Ar least one backup should be in a remote location and some should be within our reach.

Also, we should make sure that data that’s backed up is only available to authorized parties.

Not Testing Our Code

Skipping testing is a bad idea since our stuff often doesn’t work out the way we expect.

This is especially apparent with code. We should prepare for code to fail.

Testing can be automated to take the burden off our backs, so we should also do that. However, that’s mainly good for regression tests.

If we’re writing new stuff then we’ve to test them ourselves and write the test to test for regression.

Trusting Other Developers’ Code

Trusting other people’s code may be a bad idea. Everyone can be careless, so we probably shouldn’t trust them too much,

That means we should always review other people’s code and solutions to check if there’re any issues with it.

Duplicating Features

If there’s already a feature available in our code that we can use. We should use it instead of reinventing the wheel.

It’s better to use time-tested code than writing new code that does the same thing but may have more bugs.

Conclusion

We should only write code when we know what we’re doing and why we’re writing it.

Also, reviewing other people’s solutions to check them for flaws. In addition, we shouldn’t duplicate features and use time-tested code.

Being a good remote worker takes a lot of discipline. We’ve to do everything ourselves without anyone watching.

In this article, we’ll look at some habits we can adopt to become a good remote developer.

Commit to Doing More

Since we have extra time because we skipped the commute and don’t have to do anything other than work and have meetings, we should commit to doing more.

This way, we’ll convince everyone that we’re good workers even if we aren’t inside the office.

With all the extra time, we can do more and take more breaks.

Therefore, for developers, this means that we can take on more tasks and work harder than if we’re in the office.

This is also important since nobody can see if we’re working or not, so we got to get more stuff done so that people will be happy with us working from home.

Work When We’re the Most Productive

One great benefit of remote work is that we can take advantage of working at different times as long as we get stuff done.

Therefore, we should take advantage of that so that we can maximize our work throughput.

If we do have a time where we solve things a lot faster, then we should take advantage of that.

Save Calls for the Afternoon

The afternoon is good for calls since our brains can use a break after working hard in the morning when our brains are freshest.

Taking calls and meetings let us take a break since we don’t have to think as hard as when we’re debugging and looking at all sorts of weird issues that come up all the time.

This is especially useful for getting through the afternoon lull where we had lunch and we’re more tired than in the morning.

Plan Out What We’ll Be Working On Ahead of Time

We should plan out what we’ll be working on ahead of time since we don’t have anyone to guide us on what we’re working on.

Therefore, we should be planning this out ahead of time so that we can do them soon.

However, we can change the priorities so that we can do different things at different times.

This way, we won’t forget this and we can do them as soon as we planned them.

Listen to Music

We can play music while we work so that our environment won’t be too silent.

While we work, we can get the playlist that we can want and then play it so that it won’t be too quiet.

Communicate Expectations With Any Stakeholder

Since we’re working remotely and can’t see each other, we got to communicate everything clearly with us.

This includes the tasks that we need to get done so that they’ll know the progress of it.

If we don’t communicate, then no one knows what we’re doing, which isn’t good since we’re probably invisible to them even if we’re actually doing the work.

We don’t want to be invisible if we’re working remotely so that people will actually appreciate our existence.

Therefore, we got to know that we’re giving results by communicating that we’re doing something.

Prepare Meals

If we want to save money, we got to cook ourselves. We can make time to cook at home since we’re already at home.

Therefore, it’s a great idea to save money if we prepare our meals at home.

This is another great thing that we can do if we’re working from home.

Pick a Definitive Finishing Time

At the end of the workday, we got to cut off any work things from our lives for the next few hours until we go to sleep and wake up again.

This way, we have actual times for breaks and then we can do something else like hobbies and anything else that we want to do.

Keep the TV On In the Background

TV shouldn’t come in the foreground until we’re getting off work. TVs are distracting and it’s especially bad if we’re doing hard things like debugging and running things in production.

Therefore, we should turn it off and just focus on work.

Conclusion

We should focus on doing work and remove all distractions. Also, we should save money by preparing meals and plan out what we have to do ahead of time so we don’t forget about that stuff.

Also, TV isn’t very useful for most people, so turn it off and, finish our work, and then turn it back on.

It’s easy for developers to make mistakes, but we can prevent them if we know them beforehand.

In this article, we’ll look at mistakes that back end developers make.

Deploy on a Friday

If we don’t want to fix problems on the weekend, then we shouldn’t deploy on Friday.

Any deployment is risky and we should always think twice before doing if it’s not an emergency.

Things never go the way that we expect. And we definitely don’t want to ignore anything bad that comes up on the weekend and have angry customers to deal with on Monday.

Bad Input Validation

Server-side input validation is important. They serve 2 purposes. We need them to ensure security and also to prevent corrupt data from being saved.

We have to prevent SQL injection issues so that attackers can’t run malicious code to do whatever they want in our databases.

Also, we should validate input data to make sure that the data is in the proper format that we’re looking for.

If we don’t, then we’ll probably run into problems in some other places.

Most back end frameworks should be able to do both out of the box so that we don’t have to write all the code from scratch to do all that validation.

Authentication and Authorization

Authentication and authorization are 2 different things. People may not be aware of that.

Authentication is just checking for the ability to be able to log into a system with valid credentials. Authorization is the privileges that we give users.

We should make sure that users aren’t authorized to do more than they should.

For instance, if they’re a regular user, then they shouldn’t be able to view other user’s private profile. That’s an authorization.

Authentication is just making sure that a username and password or anything else that we have to enter is valid so that we can log into a system.

Ignoring Performance and Scaling

Performance and scaling are always important things to consider in the back end. We don’t want our systems to time out when we’re dealing with too much data.

Therefore, we should consider caching, doing long-running jobs in the background, pagination, etc. These are things that’ll help us prevent overloading our servers.

It’s bad if our app is overloaded since it’ll fail before it can do what customers want.

Not Running Resource-Intensive Processes in the Background

Resource intensive jobs like report generation, sending mass emails, etc. should all be done in the background. They’re all resource-intensive and it’s hard to do them synchronously without holding up our app for a long time.

Users will be frustrated if they’re left waiting for a long time when we have jobs running in the foreground and keeping users waiting.

Therefore, we should create background jobs for these resource-intensive tasks and batch them so that they won’t overload our servers.

Also, we should move these tasks to run on their own servers so it won’t overwhelm the main app.

Not Optimizing Bandwidth Usage

We should minimize bandwidth usage in all communications. For instance, we may be sending large chunks of data or images between multiple remote servers.

To make the transfer process more efficient, we should compress everything before sending it to save bandwidth. Then they can be decompressed on the receiving server.

Using RESTful Anti-Patterns

REST API should follow some basic best practices. For instance, the HTTP verbs to match the database operations that they’re doing.

GET should retrieve data, POST should create data, PUT and PATCH should update data, and DELETE should delete data.

This way, no one will be confused as to what our code is doing.

Also, our endpoints have to send the right HTTP status codes. 200 series is for successful operations. 400 series for errors coming from client-side and 500 series errors for errors occurring on the server-side.

For instance, 401 is for unauthorized, 403 means that we’re forbidden to access a resource because of a lack of privileges, 404 for not found, 502 for timeout errors.

Conclusion

We should stop ourselves before committing these mistakes if we’re doing back end development.

We should think about performance, scaling, validating inputs, and returning errors with the right status code.

Developers are always busy. There’re always things that come up like bugs and new features that we have to spend working on.

In this article, we’ll look at all the useless ways that we can spend our time as developers.

Social Media

A lot of social media is a big time sink. There’re always cat and dog pictures, and pictures of people going on vacation that we can stare at for a long time.

They don’t help us too much, and looking at photos of people on the beach while we’re working is downright depressing.

Therefore, we should get off social media and finish our work so that we can go on vacation ourselves.

Long and Useless Meetings

Many meetings that we’re asked to attend are long and useless. However, we’re stuck with it since somebody with power asked us to attend.

These are definitely productivity killers and the time we spend in these long and useless are times that we’ll never get back.

We should keep our meetings short and only attend the ones that we need to attend.

If they’re long and aren’t that useful, or if we have nothing useful to contribute, then find a way to get out. Most people are happier than we’re delivering things that sitting around doing nothing in useless meetings.

The shorter they’re the better.

Reinventing the Wheel

If there’re off-the-shelf solutions for whatever we’re doing, then we should use that.

There’re many libraries and frameworks in the world and they can probably do whatever we need already.

For instance, we probably shouldn’t be implementing our own lists or sorting algorithms for example.

A good sorting algorithm like quicksort takes specialized knowledge to implement properly, so we should probably leave it to the experts to implement it and then use their solutions.

Likewise, most data structures that we need have already been implemented by other people so we can just use them if needed.

This also goes for anything that has existing code written for it. Time-tested code is better than new code that hasn’t been tested for bugs.

We can implement something that we have implemented before from scratch to understand them more. But if we’re doing something for work, then we probably should just use existing solutions.

Fixing Spaghetti Code

Spaghetti code is bad because we don’t know what they’re doing. It’s a complete chaos and probably too complex and messy for us to comprehend.

If we have to deal with spaghetti code, then they probably just going to make our brains fry.

That’s not good at all since we can better use that time to implement new features to help customers or we can help other people that are stuck or behind on their work.

Therefore, if we have to deal with spaghetti code, we should replace them with new clean code, or find another place or team that doesn’t have spaghetti code in their codebase because this is bad code that tortures people’s brains.

Not Asking For Help When Stuck on a Problem

When we’re stuck for a while, we should ask for help. More likely, than not, someone can get us in the right direction.

Therefore, instead of trying things to get unstuck ourselves, we should find other people that can help us get unstuck faster.

Premature Optimization

If we don’t need to optimize something now, then don’t do it. We know that we don’t need it if we don’t run into problems in our own performance tests.

We can leave that stuff for later. However, it’s important to make our code easy to change so that we can do any optimizations that are needed when required.

Perfectionism

There’s no such thing as something that’s perfect. Therefore, striving for perfectionism isn’t a very good goal.

All we need is a good solution that works for our users. Of course, we should still think of the use cases that users go through when they use our app, but we don’t need to be obsessed with perfectionism.

We need to deliver our stuff and that’s much more important than writing perfect code.

Conclusion

Long and useless meetings don’t do us any good. It’s time that we can use to deliver things. Instead, make them short and useful or skip them.

Social media can be a big time-sink. We shouldn’t look at them if we have work to do.

Spaghetti code should be thrown out and replaced with some clean code. They’re just too hard to work.

Also, we should stay stuck on anything, including perfectionism.

Once they’re all eliminated, we’ll have free time to enjoy ourselves.

It’s easy for developers to make mistakes, but we can prevent them if we know them beforehand.

In this article, we’ll look at mistakes that developers make.

Trusting User’s Input

We should never trust users’ input into any software. Instead, we should assume that they’ll enter invalid data.

Letting them enter invalid data will contribute to corrupted data in our systems and we’ll run into problems later on.

Therefore, we should never trust them and validate any data that are entered by users.

This includes both client-side and server-side validation. Client-side validation is used to tell users that what they entered is invalid. But we also need server-side validation to prevent bad data from being saved to our systems since bad data can be entered easily.

Manual Tests

Manual tests should be minimized since they take so much time. It’s just annoying to test all features of our apps manually.

It takes a long time and it’s boring and repetitive. Computers are good at doing repetitive tasks. Therefore, we should let them do it.

We should write unit tests to test small parts of a system like functions and classes.

Also, we should write some end-to-end tests to test the behavior of the full system to see if they work well.

Skipping Documentation

Without documentation, no one would know how to do anything. We have to write documentation so that people will know how to do things like setting up a project locally.

Also, we need documentation for our product so that people know what it’s supposed to do.

More importantly, we should make sure that documentation is up to date so people won’t be misled by outdated documentation.

Skipping Logging

We got to log activities that are done by our systems so that we know what it’s doing and we can find out what things are causing issues when things go wrong.

With error logging, we can check for recurring errors and fix them faster.

Also, we need an audit trail so that we know what users are doing is what we expect and no malicious activity is going.

Being Careless as a Privileged User

Any privileged user has more power to do things. An admin makes have the power to mess up databases by modifying or deleting data.

Therefore, we should always think twice before doing that. Even if we have backups, it’ll be a pain to fix issues with data after we screw them up.

Also, we should be careful with any server operations. Even though many apps are hosted in sandboxed containers, we may still mess things up if we aren’t careful or if we don’t know what we’re doing.

Scattered Configuration

Configuration files should be in one centralized location so that we don’t have to look for them everywhere.

This way, we can find them easily and keep track of them easily. Making changes will also be easier if they’re in one place.

It’s also easier to safeguard things if there’s only one place to safeguard our configuration.

Hard Coding Values

We shouldn’t hard code values that are constants. So we shouldn’t have values written in our code as magic numbers.

Instead, we should put them in as constants so that we know what they’re for.

Burnout

To prevent burnout, we should always take breaks. Taking breaks lets us recharge and think about things in a different way.

We always need a vacation and they’ll be more productive than working nonstop since it’s easy to screw up if we work too long.

Not Learning More

Computer and software change all the time. We should learn more things so that we can use them later.

Sooner or later, we’ll have to learn them so we should just take the plunge now. Learning it fast will be a lot harder and more stressful since there’re probably deadlines.

Without deadlines, learning things is more comfortable, since we can learn at our own pace.

Conclusion

We shouldn’t make mistakes about when developers. If we’re too fixated at our jobs, then we’ll make these mistakes fast.

They’ll stifle our success since they’ll affect us negatively in one way or another. For instance, messing up user’s data is definitely bad and we can’t let that happen.

Letting our skills get outdated is also bad since we may become unemployable in the future.