DEV Community: Stephen Miracle

Self Confidence is My Superpower in Software Engineering

Stephen Miracle — Tue, 28 Jul 2020 15:19:30 +0000

What’s the most unexpected but important requirement to becoming a good software developer?

Self-confidence.

You must be confident in your ability if you want to succeed as a programmer. It is still important to maintain humility. These concepts aren’t diametrically opposed to one another. You can have strong self-confidence and humility at the same time.

You must maintain a healthy dose of honest self-confidence in your work.

It is sad but I’ve met many competent programmers who fail to reach their potential. It isn’t because of a lack of ability, technical expertise or critical thinking.

They fail to reach their potential simply because they lack confidence in their abilities. They compare themselves to their peers, doubt themselves and listen to bad criticism.

They continuously set themselves up for failure.

Over and over again, good engineers with poor self-confidence miss out on awesome opportunities by their own destructive habits because they tell themselves that they can’t succeed.
Now let’s be real about what actually is and isn’t self-confidence.

Confidence != arrogance

When I say that confident engineers succeed, I don’t mean arrogant engineers. We all have known those engineers who believe their work doesn’t stink and yours is garbage. The engineers who go into a code review and tear apart your good feature with over the top criticism of naming conventions and spacing.

disclaimer: Not discrediting naming conventions or spacing. Just showing examples of where some engineers go overboard with such criticism.

Arrogant engineers aren’t confident engineers. Most of the time, the arrogance is just a facade covering their lack of confidence.

Be confident. Don’t be arrogant.

Confidence == belief you can solve problems.

Confidence in programming really comes down to 1 belief. Confident programmers look at problems and know that they can solve a problem with code. You may not solve it the same way as someone else. You may program the solution and realize that you did it wrong. It may not be the prettiest or sexiest.

You just listen to problems and believe that you have the ability to solve them.

Confident Engineers Have High Expectations For Themselves

I believe in my ability. I know that if I am put into a room and asked to program a solution that I will succeed and succeed well. I have high expectations for my abilities.
This means that I must either live up to those expectations or I am delusional.

I might’ve been delusional as a teenager thinking that I, a 5’8 kid with no athletic ability, would play in the NBA but I have learned from those embarrassing experiences. If I say that I can do something then I want to be able to back it up and show that it’s true. Therefore, I am always pushing my skills to improve.

Confident Engineers Learn From Everyone

Confident engineers know that everyone can help develop their own skills. They can listen equally to superstar engineers they follow on social media just the same as a junior engineer recently graduating from a bootcamp. Everyone has their own experiences and insights and you can learn from them.

Confident Engineers Know When to Listen and Ignore Criticism.
Not all criticism is good. Engineers with low self-confidence will listen too much to critics with little substance. These critics are the loudest but provide little to no benefit. Engineers with strong confidence know to ignore these people as they generally just enjoy hearing their own voice.

Good criticism doesn’t come from the loudest or most accomplished person. Instead, it comes from those who are invested in who you are or what you are doing. This doesn’t mean all customers or peers. Many of these people want to see you fail or just complain. They don’t provide value.

Focus on finding the right people that become invested in you. Their criticism will be pointed, detailed and constructive. It will be pointed not at you as a person but towards behaviors and activities that you can adjust.

Confident Engineers Produce Better Work

Engineers who lack self-confidence in their abilities find themselves in a negative catch-22. They produce bad work which only reinforces the doubt in their abilities.

The quality of work you produce is 100% connected to the confidence that you have in your ability.

If you believe that you produce superior work, then you’re going to live up to your standards that you set. If you doubt your abilities then you’re going to produce poor work. It is really important that you find 1 thing that you know you can do well and expand from it. You don’t have to be the best engineer at everything. Just do the best you can at even something small. You’ll discover that the reason why you excel in some areas but not others is that you enjoy some things more than others.

No engineer is great at everything. Confident engineers know there is a place for everyone to succeed. It’s important to discover where you best fit.

Confident Engineers Don’t Compare Themselves to Other Engineers

In the end, confident engineers know that their worth and abilities are completely independent to other engineers. My ability to succeed is not coupled to your ability to succeed. We may look at the world differently and we may solve the same problem in seemingly different ways.

But I am good at what I do because I have both succeeded and failed in my experiences. I know that my end result may lack in an aspect that other engineers find important. It is also true that the same could be said for me evaluating the work of other engineers.

My self-confidence in my abilities really comes down to the fact that I truly believe that if someone comes to me with a problem that I can find the right solution to make them happy.

Secret to Good Programming? Documentation Driven Development

Stephen Miracle — Mon, 13 Jul 2020 21:49:07 +0000

So the title of this article is a play on "whatever driven development. I'm not really advocating for a new or different style of programming.

I am encouraging you to start documenting before you even start coding.

I'll be honest. It took me forever to actually start documenting my code. I've always been a supporter that code should be "self-documenting". But, in reality, this was just a pure lazy stance on my part.

No matter how well written my code was, I could not for the life of me read it again after 6 months.

Why did I write that logic that way?

If I couldn't read it in 6 months, how could I expect other engineers to understand my interesting attempts at programming?

I'll tell you -- By being pure evil.

It can't happen. It doesn't happen.

If you want to know the easiest way to make sure that functionality gets duplicated in a system.. Don't document your code.

Other engineers will surely just ignore your code and write it again differently.

But I'm not here today to harp on why you are evil by not documenting your code. There are plenty of other articles on the Internet that can do plenty good making you feel bad.

I am more interested in sharing something really neat I discovered when I started to get serious about documenting my code.

It made writing my code faster and easier.

Writing logic in a human language before you write the code functionality makes your code better.

1. It fills in the gaps.

Let's be honest. We start writing a function and don't really understand how it is going to get to the desired result. We know that we want to return a string that has been modified by some api. But we don't really know how we are going to the end result. We just know that we will.

What if you documented the steps first?

Brilliant.

What if you wrote down in a human language the steps required to fulfill this functionality need. In order to fulfill this function, you need to do X, Y, Z.

Write it down. Then just program it.

 /**
 * toSlug takes a string and returns a url friendly slug.
 * 1. lowercase the string.
 * 2. Replace all non-alphanumeric characters with hyphens.
 * 3. Trim white space.
 * 4. Remove duplicate hyphens.
 */
 toSlug(str: string): string {
 ..

2. It prevents useless code.

Sometimes, we write code that really doesn't belong. We think it does and we think it solves problem A. But by the time we finish, it isn't adding any value and we forget to remove it.

Unused code is terrible code.

Writing documentation before writing code prevents unused code because it gives you a chance to think through the logic. You can write out the reason "why" you need the function in a human readable sentence before programming it.

And many times, you come to the conclusion that there is another (better) way to solve the problem that already exists.

3. It prevents bugs.

Ever have a stupid bug that was difficult to dissect? It's likely because the logic wasn't really documented well. Those facepalm moments take hours or days to uncover but are really simple fixes.

Best way to solve them?
Document first.

When you write out your logic. You can check and recheck it fairly easily. You write out your logic to return back a variable on an object but then realize what if the variable is null? Add some documentation and good to go.

 // We need to check that the user exists before returning data.
if (!user) {
  return {};
}

4. It Makes Tests More Complete.

Unit tests are the holy grail but nobody knows what to test. Sure, create a test that makes sure if you pass in a string that it returns back a concatenated string. But that is the bare minimum.

Which constitutes 90% of all tests. It checks that the response returns back the right type and result for a single request. It doesn't offer up limits or provide multiple options.

Tests are generally written to succeed with best case scenario. We are told tests should be written to fail but rarely is that true. Most of the time, tests are written to pass.

This isn't the case if you document first!

When you document first, you have plenty of testing scenarios and opportunities. You know your limits. You know what can fail. You know what to check.

In other words, good documentation can actually make those silly tests useful.

Documentation Driven Development is the Secret to Good Programming.

We always think of documentation for the stranger programmer in the future that may or may not exist. It is always about the future state.

But this is far from the truth.

When you start with documentation, your code is better and you level up as a software engineer.

There's an old adage that says "What separates a hobbyist programmer from a professional engineer? Documentation."

It is true.