Category: Careers

Writing software is hard. Therefore, there’re many ways that we can mess up.

However, if we’re aware of them, then we may think twice before doing the wrong thing.

In this article, we’ll look at some mistakes that many developers have made before.

Committing Code in the Wrong Branch

Committing code to the wrong branch is something that’s been done a lot.

Since we’re supposed to make a new branch for even making the smallest changes, we may do this a lot.

Worse yet, we force pushed the wrong branch and overwrite the commit history of a branch that we shouldn’t.

We definitely let that happen.

We can protect our branches that we can’t mess up on so that we won’t accidentally commit the wrong things to them.

Hacky Code

Hacks will bite us in the long run. Unless our code ios total throwaway code, we should think about the long term consequences of our hacks.

We may write crappy codes that are hard to read so that others can’t work on it.

Also, we may run into problems later when we try to change our code or when new change requests come in.

We shouldn’t write a hacky code for anything that is used for years.

This way, we won’t run into problems later on.

Code That’s Way Too Fancy

Code that’s too fancy is also a problem.

Anything over-engineered is bad. If we should make our code easy to changes, but we don’t have to incorporate everything in the get-go.

If we can keep our code simple, then we should keep them simple.

No code is a lot better than code that we don’t need.

Also, we don’t want to write code that’d overly clever. This way, we don’t have to make others read code that are hard to understand.

Hard to understand code is definitely not pleasant for anyone to read or work with.

Underestimating the Workload

We should always give generous estimates that give us plenty of time to do the work.

Therefore, we shouldn’t underestimate the workload that something takes to be complete.

If we underestimate, then we’ll disappoint people that are looking forward to our stuff after a short time.

We’ll also be under pressure to rush out our code, which isn’t good.

Assuming we Don’t Need to Test Your Code

Any small change can break something.

Therefore, we should make sure that we test our code no matter what we change.

Changes never end up like what we expect.

Therefore, we should always test our code so that they do what we expect.

We should write automated tests so that we can test faster.

Reinventing the Wheel

Reinventing the wheel isn’t good. It’ll slow us down and create duplicate code.

We don’t want that. If we can reuse something that’s already there, then we should do that.

This way, we work faster and we don’t have to write everything from scratch.

For instance, JavaScript arrays have lots of methods to make manipulating arrays easy.

Therefore, we should use them to manipulate arrays instead of using loops.

Reinventing the wheel is often because of ignorance.

Therefore, we should know the language, libraries, and frameworks well so that we won’t implement the same thing that are already available somewhere else.

Committing the Wrong Files

Committing the wrong files can also happen.

It happens easier if we don’t see what we’re committing graphically like when we commit our code with the command line.

Therefore, it may be a good idea to visualize what we’re committing by using a graphical client for the version control systems that we’re using so that we can see what we’re committing clearer.

Code is Never Self-Documenting

Some code may need explaining. Even if we know the workflow from the code, we can still use comments to justify decisions and tell people why something is done the way it is.

Writing comments that explain why will help everyone know the code better.

As long as we aren’t just repeating the code what the code says in our comments, we should leave some comments.

Conclusion

To avoid mistakes, we should learn more so that we don’t reinvent the wheel.

We can avoid branching and commit mistakes by protecting branches and using a graphical version control client.

Hacky code will always come back to bite us later. Unless we write throwaway code, we should think about that.

Finally, we may want to leave some comments to explain our decisions in our code.

To be a good programmer, we should follow some easy to adopt habits to keep our programming career long-lasting.

In this article, we’ll look at better ways to communicate as a developer.

Choose a Style

We should adjust our communication to the audience. Not everyone wants to take in information the same way.

Some people want lots of detail and some want to stick to the point.

People want to read long reports and some want simple memos.

Therefore, we should adjust to their style so that people listening to us and reading our things will have a better time to understand our information.

Present Our Message Nicely

We have to present our message nicely so that we can convey them to our audience in a way that they’re happy with.

We shouldn’t only focus on written communication. Verbal communication is also important.

If we’re writing written documents, we should make the nicely formatted.

If we can’t make them nice ourselves, we can use templates to help us make them look nicer.

Also, we have to check the spelling and grammar of our work before presenting it to our audience. This way, we won’t embarrass ourselves with such mistakes.

Involve Our Audience

When we’re presenting something, we should engage our audience by getting feedback and pick their brains so that we can improve on our work.

This way, we can produce a better document than if we just write the whole thing ourselves without consulting anyone.

Be a Listener

We got to listen to people so that we can get their views on things.

Also, if we listen to people, then they’ll listen to us.

Therefore, we should encourage people to talk by asking questions or have them summarize what we tell them to make sure that they got what we said.

This will make getting our point across more effectively and learn something.

Reply to People

When we get a message, we should reply to them. It’s impolite to make people wait a long for an answer and it’s even worse if we just ignore them.

Therefore, we should always respond to messages and emails and check our notifications often.

Email Communication

Being careful with our email communication will save us. We should proofread before we send so that we won’t send out messages with typos or wrong information.

Also, we should check the recipient to see if it’s the right person or people before sending it.

This is especially important if the email has sensitive information.

Also, we should check the spelling of our emails to make sure that everything is right.

The formatting should be simple so that people with any email client can read them clearly.

If we use rich text or HTML emails, then we should make sure that all recipients can read them properly.

Quoting things should be kept to a minimum so that we won’t have to read everyone’s quotes.

If we do quote, then we should attribute the quote to the person that wrote the quote.

Flaming is always wrong. We should be polite even if we’re sending emails.

Also, we should organize our emails so that we only see the important stuff. The rest can be archived.

Sketch Boards and Storyboards

Diagrams are always good. We can put them on whiteboards, documents, messages, etc to convey what we want other people to know.

A picture is worth a thousand words, so one diagram can replace a thousand words.

Most people just understand diagrams better than a wall of text.

We can draw stuff with markers on whiteboards or we can do the same with virtual whiteboards and make things nice.

This way, everyone can explore ideas and make discussions easier than just talking and writing out words.

Flowcharts

To discuss workflow related things, flowcharts are always great. We can draw them or we can use a program to create them.

There’re many programs that let us create flowcharts to outline the workflows of our programs.

The symbols on a flowchart are standard so many people will know what they mean.

Therefore we should use them and save us from taking lots of time explaining things.

Conclusion

When we communicate with email, we should think about who to send it to and check for typos.

Also, we should draw diagrams instead of writing out lots of words to explain something.

It just saves us lots of time from doing things that we don’t have do to communicate the same thing.

Interviews are always hard. It’s especially hard if we have to get technical and solve problems on the fly with code.

In this article, we’ll look at some tips to get good at interviews and nail them.

Get Good at Least One Language

Getting good at one language we don’t have to worry about language syntax in technical interviews.

Although many will allow pseudocode, we still have to know basic syntaxes like loops and how to create objects and hashes.

Therefore, we should just practice coding with one language until it’s muscle memory.

We should aim for solving tough practice problems from sites like LeetCode and HackerRank so that we can solve them when we’re asked those problems.

Read Books

Books like Clean Code and The Mythical Man-Month are always good reads so that we can write clean code and answer design problems that may be asked in technical interviews.

At least we’ll know enough to talk about something in them to make us sound more knowledgable.

Study Trivia Questions

There’re lots of trivia questions that interviewers may ask. They include things like functions that are in a language’s standard library and trick questions about the language.

For instance, JavaScript has lots of tricky parts in their language that were leftover from the past.

However, they still linger today, so that someone may still ask about them.

Multiple Practice Projects

We need to practice with projects so that we know what building real apps are like in a job.

They should do things like a real business app would do like calculations and saving things to a database.

There’re plenty of app ideas that we can use to build practice apps with, so we just have to start building with our favorite language and libraries and frameworks to need it.

Also, we should write some tests so that we’re familiar with writing automated tests and we can even should those off to interviewers to show how much we care about writing software.

Then we can host them all in the cloud so that people can see them when we show them off to people.

Learn About What the Company is Doing

We often get asked about what the company we’re interviewing for does. Therefore, we should know what they do before we go into an interview.

This is basic knowledge so we should definitely before going in.

Travel to Interview Early

We should go to the interview location early to reduce the chance that anything bad like traffic jams or bus delays make us late.

Then we wait until around 15 minutes before the interview starts before going into the office so that we won’t be waiting in the workplace for too long.

Start a Conversation

Nobody likes a boring person, so we should start some conversation with the interviewer so that we have a 2-way dialog.

Having silence isn’t good as it makes for an awkward presence. Keep silent doesn’t bode well for how we’ll fit on the team.

Ask Questions

If we have questions, we should ask. However, we should probably leave the pay and benefits questions until we get an offer. Since getting an offer is far from a sure thing, we should put those until we actually get an offer.

However, anything else is pretty much fair. We may ask about things like the development process, how code is managed, length of sprints, project timelines, etc.

Showcase Non-Technical Skills

Technical and non-technical skills are equally important. Soft skills is a must-have, so we should show them to our interviewers.

Also, it’s good for interviewers to know that we may potentially fit in their team.

We should think about our soft skills, in addition to our technical skills. Whether the interviewers choose us or not probably depends on both technical and soft skills.

Soft skills include things like communication and thinking, which we can show to interviewers in an interview readily.

Conclusion

Practicing our technical skills with projects and sites like LeetCode and Hackerrank is probably a good idea before an interview.

Also, we should be good at our soft skills as well. Skills like communication and thinking are great assets.

We should have lively and not awkward conversations.

Being a developer is hard. Not only we have to know technical skills, but we also have lots of soft skills that we’ve to get good at.

In this article, we’ll look at the ways that we can get better as developers.

Build a Big Side Project

Side projects are great for practice. Bigger ones mean more practice. It’ll give us so much practice that whatever we used will become muscle memory.

We can build bigger apps like a Facebook or Reddit clone. If we’re building our own Facebook clone, then we can build all the features including chat and friends features.

If we’re going to build a Reddit clone, then we build out the subreddit and moderation capabilities.

These are examples of a big side project that’ll give us lots of practice. We can build it with the frameworks and languages that we like to learn more about and then so that we can understand them more.

Contribute to Open Source

Open source projects are everywhere and they all need help. So we should contribute to them so that we can learn and they can get help.

That way, we’ll learn about forking repositories, making pull requests, committing code, and more.

It also means that we can follow their conventions and guidelines.

Working on community packages is also different from working on a regular job so we can get different kinds of experience than a typical job.

Alternatively, we can build our own packages and reveal the source.

Look at Other People’s Code

Other people’s code provides us with wisdom that we probably don’t have. It’ll expose us to different styles of programming and show us things that we can do with a programming language, library or framework that we probably haven’t seen before.

If the code sucks, then we can also learn from them and avoid the bad practices that are exhibited in the code.

Understand Programming Design Patterns and Principles

There’re many design patterns and principles that we can look into.

Some principles include SOLID, KISS, YAGNI, MVC, and many others.

SOLID is a good one to know since it’s a good way to organize our code. It means that we divide our code into parts that do one thing.

Also, code shouldn’t open for modification but should allow for extension.

It also enforces designing code by contract by having a fixed interface while the code implemented it can change.

Abstractions are also encouraged and make high-level code independent of the low-level details.

KISS stands for keeping it simple, sweetie. It’s obvious, simple code is better than complex code if they do the same thing.

YAGNI stands for You aren’t gonna need it. It’s similar to KISS and it’s all about not adding code unless it’s necessary.

MVC is pretty much the standard pattern for back end apps with the model being the data layer, view for presentation, and a controller to connect the model and view together.

Learn High Demand Skills

This goes without saying. We can always learn high demand skills in areas that we enjoy working in so that we can get a job we like.

If it’s something we don’t like then we won’t enjoy it. And if it’s something that has no demand, then there’s no job that uses it.

So it has to be both together.

Design Skills

Design skills can be learned by anyone. We can focus on making things prettier by learning from designers and then applying when we’re developing UIs.

User Experience

We’re building things for customers, so we should always empathize with the customer and build some that have good user experience so that they’ll enjoy using it.

Simplicity, usability, consistency are all important principles with user experience.

Conclusion

Building a big side project will give us plenty of practice until what we do becomes muscle memory.

Looking at other people’s code no matter if it’s good or bad. We just need to look at them and learn lessons from them.

If it has good parts then we learn them. If it has bad parts, then we learn not to do them.

Non-development skills like design and user experience are also important and we should learn them as well.

To be a good programmer, we should follow some easy to adopt habits to keep our programming career long-lasting.

In this article, we’ll look at better ways to learn, communicate and think like a developer.

Seizing Opportunities for Learning

Taking on personal challenges to find answers is the key to success.

There’s no better way to learn by challenging ourselves and practicing to solve problems.

The web is out there and we can search it with our fingertips.

Also, we can go the traditional route and visit the library if we like physical books.

In addition to reading books, we got to practice what’s mentioned in books or whatever material we’re looking at. This way, whatever we learn will actually stay in our minds.

There’s just a no better way to become better than by learning by getting our hands dirty and challenging ourselves.

The tough challenges are what we remember the most.

Critical Thinking

Even though books and online materials are good, we got to be mindful that not everything in books and online is good or correct.

Therefore, we should keep an open mind and think through everything before accepting whatever is in them is the right answer.

In addition, we should keep in mind that lots of things are commercialized. People that can pay for ads can put their results on top or have a bigger space than other entries in a search engine.

We should keep that in mind so that we can think about them before accepting whatever is presented.

What we read and hear aren’t always truthful or correct. Content on social media and websites are often biased or misleading, for example.

Therefore, we should think about those carefully as well.

When we see or hear something, we should as specific questions.

Then we should look for answers to the questions we raised.

We can then ask those questions privately or publically depending on our preference.

Communicate

Communicating is very important. We got to keep people up to date on what we’re doing so that we won’t step on each other’s toes.

Also, we have to clarify the requirements of what we’re working on so that we can do them properly.

Our code is also a way that we communicate. It’s communicating by explaining what we’re trying to do by listing out the operations that we’re trying to do to implement some features.

We write proposals and memos to make suggestions for solving different problems and advocate for ideas.

Since we have to communicate to get anything done as a team, we got to do this well.

We got to know to say when we’re communicating. We got to think before saying or writing anything.

Technical documents should be planned our be writing. Make sure that we didn’t miss anything in our documents so that people reading them won’t miss what we’re trying to convey.

Know Our Audience

We got to write and say things that target the audience that we’re communicating to.

For instance, we would communicate differently if we’re communicating with a technical or non-technical audience.

This way, people actually understand what we’re saying when we tell them something.

This is the same for writing. It’s not just about saying what we thinking we want to say, we also have to make sure that we have to know our audience so that they’ll understand what we’re saying or writing.

Choose Our Moment to Convey Our Message

Choosing an appropriate time to say something is important.

It’s best to choose a time when people are focusing on work to talk about work stuff for example.

No one wants to talk about non-urgent work things when they’re off. They all want a break.

We should just make sure that people that are listening to us actually want to hear what we’re saying.

Conclusion

Communication is pretty important since most of us are working on a team. We got to our best to communicate so we won’t run into issues with miscommunication later on.

Also, we should take the best moment to communicate our message.

Finally, we should take everything at face value. No matter what we hear or see, we should think about them before accepting them.

We should ask questions whenever we can.