I often hear people talking about impostor syndrome and time management issues. Sometimes I hear about these issues from a friend, a direct report, and occasionally from myself. We are always challenged by them and they can affect our mood, our ability to be productive, and our judgement.

We have days where everything works great and also we have bad days, where everything seems to go wrong. This emotional roller coaster can make us doubt our accomplishments and can create a persistent fear of being exposed as a fraud.

There a few things that you can do to remember that you are great:

• Keep a daily journal with notes of achievements: this daily exercise will train your brain to feel more confident.
• Focus on your strengths, especially when you are in a new role at work, use your natural strengths to add value to your position.
• Find quick wins, they will help you build a reputation of someone adept in a particular skill.

Issues with time management also impact our feeling of getting the job done. Sometimes the problem starts early on when we are assigned a task that may not make much sense.

Let's step back for a moment and think about the levels of uncertainty of a task:

1. Well understood
2. Have a few questions
3. Understood, but unfamiliar with the approach
4. Know the area, but not the direction
5. Generally unclear

How does uncertainty affect time management?

If something is well understood, it is very unlikely you will get lost in the woods and things will take as long as expected.

Starting with the level of "have a few questions", you need to be careful because the uncertainty will affect your time management and your sense of achievement.

The good news is, you can always use this problem as an opportunity to improve.

• Have a few questions: Find the best person to answer your question. If the description is unclear, go to the person who created that task. If the question is technical, talk to a developer on the team that can help you.
• Understood, but unfamiliar with the approach: If you understand the big picture but you are not confident with the approach, talk to another developer and ask for help. This is a good opportunity for pair programming.
• Know the area, but not the direction: This is a good opportunity to talk to another developer and hear their initial thoughts. They may have an opinion on how to get the task started or be able to suggest a good resource to review.
• Generally unclear: If the problem in the task is unclear, ask for clarification. If the technical approach is unclear, talk to other developers, think about having a pair programming session, and speak with other members of your team to understand how they approach their work.

Overall, facing imposter syndrome is something that we all face at some point in our careers. It is an issue that I have certainly struggled with, but find that facing these struggles provides an excellent opportunity for me to reflect on my skills and discover new areas of potential learning.

With these suggestions in mind, I hope that you are able to improve your sense of confidence and self-efficacy in your professional life.

Also posted on my blog. If you like this content, follow me on Twitter and GitHub. Photo credit: roller coaster (Pixalbay)

I'm either comfortably retired or unemployed, I haven't decided which. What I do know is that I am not yet ready for decades of hard-won knowledge to lie fallow. Still driven to learn new technologies and to develop new projects, I see the experience and results generally getting better over time (I swear I am not an optimist by nature). I now have the time to work on what interests me, and at my own pace.

The rate of change in technologies has increased markedly since I started my career writing code in a 4GL. The UI back then utilized extended ASCII, 80 characters wide and 50 lines long. It was a much simpler environment, and I could whip out a reasonable complete custom business application in a week (though back then when I was younger, an "easy" week was 80 hours). Changes to operating systems, languages and hardware did happen, but on a scale of months or even years.

I later moved from MS-DOS, to Unix, to Windows, to Unix again, to Mac OS, and now I'm back to Unix. Whereas I once developed applications, I now develop websites. I no longer code in C++ or Java, but (mostly) in JavaScript. I once considered myself very expert at C++, SQL and XML; now I mostly work with NoSQL, GraphQL, JSON and a bit of YAML. Though still competent in many areas, the whirlwind that moves at web speed means I'm not very expert at anything the way I used to be.

"Ok, Boomer, so what's the point?"

First of all, I'm Generation Jones. So watch it, kid.

What I'm getting around to is that just about every former colleague I'm in touch with that excelled at programming is still programming. To be able to do that for decades, you have to remain open-minded and adaptable, because the technological rug gets pulled out from under you all the time.

Learning does get a little bit harder the older you get (the memory's intact, but the recall's a bit sketchy). What experience gives is a grasp on how new jigsaw pieces fit the puzzle, and how to spot and avoid a fad or a failure from a mile away.

"What does this have to do with writing?"

Okay! I'm getting there... jeez.

I've just admitted I'm not so much an expert on on anything anymore. However, with all the new techs popping up every five minutes, there's plenty of bleeding-edge stuff that nobody is an expert on...and that there is a niche, my friend.

To exploit it one must: learn, research, suffer, take notes, research more, suffer some more, give up, stubbornly try again, and eventually succeed. That is called experience, which is not the same as expertise, but it is valuable nonetheless.

When I start to learn about something new, I begin by casting a world-wide net (web?) looking for somebody, somewhere that can clue me in as to what I should be doing. If I wind up empty-handed, I know that that somebody is going to be me. So I start working it out on my own, cursing the entire way.

Sometimes clues can be found in documentation, but for new stuff the docs are: 1) missing; 2) lying; 3) incomplete; or 4) unfathomable. Then I have to ask newbie questions on forums and technical support message boards, trying not to sound like an idiot (which is generally assumed by the by those responding). If I still don't get an answer, I know that I'm really on the bleeding edge.

Just so you know, I hate the bleeding edge; the bloody edge is fine--that's just a bit back from the bleeding one. Life is not near so exasperating on the bloody edge.

"So you admit you are an impostor."

Well, yeah, but hold on just a one sec...

I don't dissuade my readers from thinking I'm an expert, but I don't conceal that I just might be learning this stuff as I go along.

This brings me around to my penultimate point: the process of writing about something forces me to learn it better. I'm okay with being an imposteur (fancier French word that sounds cooler than it is), but I don't want to be a dummkopf (German word that sounds exactly like what it is). So I try hard not to write something totally wrong and stupid.

Sometimes I make a bad assumption or overlook some side-effect, but if you're too scared of embarrassing yourself, you miss the opportunity to get a deeper and more complete understanding. Occasional little dummkopf errors you made will be pointed out to you in comments, which you must acknowledge, correct, and move on. Everybody goofs, even the experts.

Finally, and most importantly, writing offers the opportunity for readers to learn something faster than author did. We should all follow DRY principles, shouldn't we? There's no reason for some poor anonymous fool to make the exact same errors that you, the writer, already made for them.

So try it! If you're not a good writer, and good editor will help you become one. I recommend Hemingway as a start. And thank you, Dear Reader, for allowing me to share!

Impostor syndrome is a real thing in software development. After 20+ years in the industry I still catch myself thinking “I should know this, how come I don’t know this yet?”

_[https://xkcd.com/1954/](https://xkcd.com/1954/" rel="noopener" target="blank" title=")

The truth is that our industry is constantly changing. There is always some hot new framework or some en vogue methodology that is being hyped to the community. When you read about something new online it can seem like EVERYONE knows about the new hotness. You think to yourself: what is this and why am I just learning about it now? Does everyone already know about this and why am I the last to find out?

Last year, it was React for me. But I have gone through this process with many technologies and frameworks over the last 20 years: Xamarin, .net core, .net standard, portable class libraries, MVVM, MVC, aspect oriented programming, functional programming, object oriented programming, composition over inheritance, test driven development, agile, scrum, inversion of control, containers, continuous integration, git, DevOps, RPC, web services, REST, JSON, XML, NoSQL, Document databases, websockets, ajax, handlebars, mustache, jquery and many more technologies that have come and gone the way of pascal.

And those are a fraction of the things that have been new to me, over the years. I could fill this page with technology and languages that have come and gone. The point is, the software industry is hard and it’s evolving. No wonder it can feel like you are an impostor in your own industry.

I love learning about new things. You have to if you want to survive in this line of work. It’s OK to tell yourself that you don’t know everything, you can’t know everything. Your peers around you might know more/less/different things than you do. Embrace that. Learn from each other. I always end up with a deeper understanding of a concept when I get to explain and teach it to another developer. You never truly learn something until you have to teach it.

When Impostor syndrome kicks in it can be depressing. When browsing online communities you can find the mentality of “what an idiot, this guy doesn’t know x”. Developers online can be cruel, even when they don’t think they are. Sometimes your own insecurity can make you feel that people are putting you down when they may not be. The internal struggle can be constant and relenting. Your co-workers may even contribute to this feeling.

Don’t put your team members or other developers down when they don’t know something. Instead, take it as a learning opportunity to grow together.

_[https://xkcd.com/1053/](https://xkcd.com/1053/" rel="noopener" target="blank" title=")

You may find yourself defending your decisions and your code so you don’t look (or feel) stupid. This will breed insecurity and everyone will end up looking out for themselves. I have learned over the years that no matter how good (or bad) you are, you will ** up. So will your co-workers. It’s how you handle the situation that will make for a good or bad experience going forward.

A terrible working environment is one where you’re not allowed to make a mistake. Employees may talk about each other behind their backs. You may hear things like: “I can’t believe how stupid Charlie was the other day. What an idiot!” If you hear a co-worker or boss talking bad about another employee, you can bet they’re also talking about you behind your back. This toxic environment will cause everyone to “circle the wagons” around themselves. Try to change the culture or get out if you can.

A pleasant working environment is where team members accept that they don’t know everything. One where you can learn from each other and work towards the same goal. Strive to be this kind of developer. You will never know everything there is to know. Accept that. Learn what you don’t know and teach what you do.

In the end, know that you’re not alone in this feeling. There are a lot of people out there who feel it too. As I have aged, I have come to accept that there are things I don’t know that other people do. How you choose to react to that feeling can make or break you. I choose to accept my limitations and strive for additional knowledge.

-K