Posted by: lrrp | March 22, 2018

Growing as a Programmer In Spite of Struggle

Most people try to hide away from pain and struggle. Instead of learning how to deal with it properly, they spend all the time in the world finding ways to avoid it.

Realizing how important it is to stick with things you are struggling with until you master them is a key skill for programmers to learn, especially because it is a field where things are constantly changing.

Do you want to be like the average person who spends most of their days trying to find ways around the struggle instead of taking the problem head-on and overcoming it? I chose to overcome the problem, and I hope after reading this you will too.

Today, I am here to tell you why struggling is important for you to continue growing as a developer and how to change your attitude so you can embrace it!

What is Struggling?

We have all heard the phrase that a friend was struggling with something, or completing that task was a struggle. What does it mean, though? Let’s clarify this so we can know exactly what we are talking about in the rest of this post.

From Google definitions service, we get the following:

Struggling: strive to achieve or attain something in the face of difficulty or resistance


Struggling: have difficulty handling or coping with

It is when you are facing a tough challenge and you are trying to find a way to overcome it. If you choose to give up or drop the struggle before coming out on the other side, you end up losing all the benefits and growth you can gain from struggling. You are simply trying to cheat.

In terms of programming, you can struggle with plenty of things. You can struggle to learn a new piece of technology when not much documentation about it exists yet. If you persist through the struggle of learning something most people do not know, you end up becoming one of the most highly desirable people in that field of expertise. Or at your job, when you are dealing with a customer who wants certain things done before an impossible deadline. How you deal with the customer to make them understand the time it takes to get something done can determine your future with that customer. If you succeed in handling the situation, then you now have better communication skills and can take that with you the next time you have a similar issue.

Perseverance is Key

When you are struggling with something, you are trying to do something you likely have not attempted to do before, or it is something you have attempted but gave up. When you give up, you do not learn how to do the thing you set out to do; instead, you are in the same position as you were when you started.

After three months of doing this on the side after work, he shows his manager what he has been able to accomplish. His manager likes what he has done and John is now working as a web developer half of the time!

It is the fact that you choose to fight the struggle that makes you stronger. When you fight the struggle, you are setting a habit for yourself not to give up, no matter the circumstances. If you never give up in scenarios where most people will, you will not be like most people. You will have the new lessons learned from the struggle.

Opportunities to Grow from Struggles

Growth through struggles does not only take place when you are trying to solve a bug (although this is where plenty of learning does happen in programming), but also in every moment in life when something does not come to you easily.

When you are facing a tough time with your family members or friends, this can be a time to show that you truly care about them and want to keep those relationships in your life, or you can show you do not want them in your life. In times when you are trying to overcome an insecurity, you can let that insecurity control your life or face the fear by struggling through it and overcoming it.

The times when struggles are presented to you can be every single day of your life or maybe very rarely. I like struggles; they cause me to elevate my skill set in a certain area to the next level. You must change your mindset to learn to embrace them rather than hide away from them.

Changing Your Mindset Toward Struggles

Now is the hard part (Oh, look, this is your first test with a struggle!). You have probably been told to think of struggles as a bad thing your entire life, but you must learn to find a way to turn them into positive things. It will not be easy and most people will not be able to do it.

Try to see struggles as learning opportunities. When you are struggling with something, you are missing some knowledge that you do not have yet. The knowledge you are missing comes from the struggle itself. If you learn to take the struggle to the finish line, you will fill that knowledge gap. This quote always helps me get through struggles and battles in life when I think all hope is lost, by reminding me that there is a benefit to every single struggle:

“Every adversity, every failure, every heartache, carries with it the seed of an equal or greater benefit.” – Napoleon Hill

Repeating this quote as an affirmation will keep you focused on the fact that within every problem, there is a greater benefit. If you look for that benefit instead of having a negative mindset toward it, then you can be more motivated to overcome it and know that backing down from that struggle is not an option if you want to be more in charge of it.

Fight Your Struggles!

Now is the time for you take action. You understand how important it is not to back down and make sure that you stick with something until the problem has been overcome. You know that your mindset needs to change from the many years of mental programming and thinking that has caused you to believe that struggling is a bad thing.

As programmers, growing from struggle is something that should be part of your daily routine. When you notice a problem, you should stick with it and attack that problem as best as you can so you can learn the lessons in it. This may come in many forms, such as fixing a deep bug, learning a new piece of technology, or dealing with coworkers and customers.

Today is the day you make this change. Go out and start fighting your problems head-on and see how much stronger of a programmer, coworker, friend, family member, and human being you will be from it!


In today’s day and age, the internet is an extremely powerful tool. With various forms of social media, YouTube, blogs, and tons of other platforms, you can reach people all around the globe within a few clicks.

Being able to interact with people around the globe means that you can trade tips with developers on the other coast, learn about best practices from companies based in other countries, and offer your own expertise to a broad community.

The sad part is most people do not take advantage of the enormous leverage the internet gives us. Many programmers believe that a personal online presence to keep up with friends and family is all they need, missing the strategic potential for a professional presence.

It allows you to be in multiple places at one time with your content. You can maximize your reach (thus effectively multiplying your work) by building on one idea across many platforms. You can also interact with more people, increasing the potential for you to get noticed and get better jobs, or become an influencer.

Let’s discuss what a professional online presence is, why you need one, and some resources to help you get started.

What Is an Online Presence?

An online presence is a virtual representation of you, with the ability to offer information and engage with others in the online world.

It usually starts with at least one of the following: a YouTube Channel, a GitHub, a blog, subreddits (or other forms on your niche), or any of the social media sites (Twitter, Instagram, Facebook, and LinkedIn).

On these sites, you create a professional profile that outlines who you are and your area of expertise. Then you engage with that community by posting either content you’ve created, links to and comments on content you find interesting or provoking, and conversation with others on the platform.

After some time, people start to trust you as someone who knows stuff about  particulat technologies. In fact, when they have questions on the topic, they may ask him for help through any of these online platforms.

An online presence allows you to build a strong professional reputation outside your company, giving you a strong, diverse network and the opportunity to influence your field.

Why Do YOU Need One?

There are plenty of reasons why you should maintain an online presence as a software developer. Let’s go through a couple of the more important ones.

Infinite Network

When you have been posting about a certain topic for a while, displaying and sharing your knowledge, other people in your specific domain and niche will find you and read your information. As time goes on, these people will start to interact with you on the internet.

As you continue to provide them value through the various videos, blog posts, or social media shares, you are building relationships with the people who follow you. This engagement allows you to build a network in your field through the internet.

Why is having a large network even useful? For meeting new people, finding new people to work with on cool side projects or business ideas, finding people that are interested in the same topics as you, and much more.

Programmers who spend plenty of their day behind computers tend to not focus on networking as much as other career areas do. Having an online presence allows you as a programmer to network in a way that is more comfortable to you (through the computer/internet).

Why Do YOU Need One?

There are plenty of reasons why you should maintain an online presence as a software developer. Let’s go through a couple of the more important ones.

Infinite Network

When you have been posting about a certain topic for a while, displaying and sharing your knowledge, other people in your specific domain and niche will find you and read your information. As time goes on, these people will start to interact with you on the internet.

As you continue to provide them value through the various videos, blog posts, or social media shares, you are building relationships with the people who follow you. This engagement allows you to build a network in your field through the internet.

Why is having a large network even useful? For meeting new people, finding new people to work with on cool side projects or business ideas, finding people that are interested in the same topics as you, and much more.

Programmers who spend plenty of their day behind computers tend to not focus on networking as much as other career areas do. Having an online presence allows you as a programmer to network in a way that is more comfortable to you (through the computer/internet).

Employers Love It

When you are looking for a job, the main thing that the employer is looking for is proof that you know what you are talking about. What’s a better way to prove that you know what you are doing than by having blog posts and videos where you are teaching people on the exact topics you are expected to know?

Going into the interview, the company will do research on your internet presence and see that you know what you are talking about. At that point, most of the battle when it comes to getting a job is already done.

On top of the automatic proof having an online presence gives you, recruiters and engineering managers at companies will start to reach out to you because of all the information you have put out there. They are scouring the internet at all times of the day, looking for people who know what they are talking about on a certain topic. Now, coming from this position puts you in a position of even higher leverage when looking for a job, because they want you going into it.

Great for Freelancing/Online Business

If you are not looking for a job, do not worry, I have something for you as well. Having an online presence is even more useful if you are trying to start freelancing or to create an online business.

If you want to do freelance work, and a prospective customer sees that you have written and taught other people on the exact topic they need work done in, they will assume that you know what you are talking about. If they assume that you know what you are talking about, it will allow them to trust you over all of the competition out there. Who do you think a hiring manager is going to chose for a job? The person who has nice videos and helpful posts teaching the information on the internet? Or someone who just says they can do something through a resume?

What if you want to have your own business? Then you could charge people for private lessons teaching them in your area of expertise, or create courses such as “How to Become an Amazon Alexa Developer” and sell them to many of your followers who already trust you.

So, How Can You Create an Online Presence?

I am a huge fan of making things as simple as possible so action can be taken right away. What is something you can do right now to build an internet presence?

In my opinion, the easiest thing you can do to get started is to create a Twitter account (this platform is where programmers tend to be more active). I recommend this to anyone starting out and looking for the easiest first step when building an online presence.

You don’t even have to tweet any of your own knowledge. Simply tweet one piece of content, whether it be an open-source repository, a blog post tutorial, or an opinion article on something in your field. Tweeting links to content isn’t the most effective long-term strategy, but it’s the simplest thing you can do right now to get started.

If you want to build a presence faster, then I would suggest posting on all platforms, a couple of times a day. The multiple platforms include a website and blog, a YouTube channel, Twitter, Facebook, Instagram, and a Reddit account. Posting this much can take plenty of time to do every day and is a more advanced form of an internet presence. It can be overwhelming for someone just starting out.

I would pick one platform and practice until you get comfortable with it, and then add in another one. Personally, I began with Twitter, then started a blog, then created a YouTube channel, an Instagram account, and finally, I jumped into Facebook. I spent time building the habit of posting regularly on these accounts and then added more and more as time went on. This process prevents yourself from getting overwhelmed and gets you started today!

Resources to Help You Get Started

In my opinion, the best forms of social media for programmers are YouTube, Twitter, a blog, a GitHub, and then any forms/subreddits that relate to your field. These websites allow you to either showcase your code, teach others about code, or share interesting and relevant news in the programming community.

If you are looking to start a YouTube Channel, look at how others have done it .

A really great forum for programmers is Hacker News. GitHub is a little different; you create open source projects for other developers to work on. Or you can become a contributor on other developer’s existing projects, or you could fix bugs in those projects.

Each different platform has advantages and disadvantages, but you can pick one or more based on what you like.

Go Take Action!

As the internet gains popularity, and people spend more and more time on it, your online presence will be even more important and valuable. It takes seconds to create a social media account. Chances are you know something that can benefit people out there somewhere in the world.

With the awesome benefits you can receive in return, there’s almost no reason you should not start. It allows you to have a nearly infinite network of people you know around the world, which can come in hand for plenty of reasons. If you never want to be without a programming job, then this is a sure way of making sure people will hire you. If you have a business or are a freelance developer, then your internet presence can be a way to land more gigs or get more clients.

It may take some work over the long term, but if you are consistent, you will start to gain some traction. The information given to you here was meant to be used to help you, not for reading pleasure. So, go get out there, take massive action, and take advantage of the internet today!

Posted by: lrrp | March 20, 2018

Three things to keep private…..

Posted by: lrrp | December 16, 2017

Why Finishing Software Is Hard. And What To Do About It.

Yes, The Last 10% Is Hard.

“The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time”

— Tom Cargill, Bell Labs (ancient software wisdom — if you know an Agile equivalent, I’d love to hear it)

There’s nowhere to move the deadlines — time’s up. The thing you are building, which used to feel like a set of well-understood building blocks, now streams towards you in an endless river of barely connected details. UX wording needs to be exactly right; reliability, which was “good enough for beta” now needs to be 100%; that niggling bug everybody has been working around for weeks needs to go away, today; a feature that you thought worked great is missing something — not clear what it is, but it is clear that the beta users have to have it; the CEO has an idea and…

The more you do it, more you learn to pattern match on traps you’ve fallen into in the past. But I’m not sure anybody ever learns enough to bring their projects into the final deadline smoothly and without stress. (Maybe you do — if so, let everybody know your secret). There’s something more fundamental going on here.

Why Finishing Any Creative Project Is Hard

We think of software as “engineering”, which gives it a mechanical, logical feel. Some of it is. But mostly, software is a creative act. Parts are knowable: they are understood libraries, or built to known templates, but the most interesting, the coolest parts, aren’t.

Creating those pieces is more like writing — the engineer (coder? writer? yes, writer), is translating a set of abstractions (business requirements, wireframes, architectural outlines) into expressions of those ideas in language.

And like writing (or painting, music, sculpture — anything), we discover software as we make it. We can sketch, plan, write user stories and build prototypes, but however diligent we are, those are representations of the thing, not the thing itself. We can only discover the thing itself by building it. We accept this for writing novels (who would ever publish a first draft?), but we are less comfortable applying this to software. For some reason, software is still “engineering”, and “engineering” is seen as precise, knowable (yes, even when we’re deep into Agile and Lean). It isn’t.

The last 10% is hard because we can’t know what the “last 10%” is until we get there. That’s the nature of the creative process. All the final details, the hidden difficulties, the polishes that make a piece of software (or a novel, or a song, or a sculpture) brilliant don’t fully reveal themselves until the rest of the structure is built. The software “tells us what it wants to be” — we have to build it to find out.

Why People Don’t Like Finishing

And then there is the uncomfortable fact that a lot of people don’t actually like finishing things. We do like being finished, which is different. It’s that lovely sense of having something behind us, of completion. We really want that. Especially during the long “last 10%” which is so much more work than we expected. We badly want that lovely hit of dopamine, that change, that relaxation, that comes from being finished. So, as humans, we gloss over details, try and ignore user feedback, hope that a patch to a reliability problem will hold, and generally avoid the hard truth that it isn’t done yet.

And then there’s the fact that the world is eventually going to see our work, and judge it. It’s scary. So we put off exposing it to the outside world, because the outside world is going to tell us what it thinks (whether the “outside world” is beta testers, your investors or your buddies at the co-working space). It’s the “nah nah can’t hear you” approach: as long as we don’t let anybody see it, we won’t suffer the possibility that it isn’t done yet.

We want the answer to the question “is it beautiful?” to be “yes”. And for quite a while, the answer will be “no, not yet”, or “no, not even close”. Scary to hear. So we’d rather “polish a few things”, or “just do another pass”, or “get the design exactly right”. Anything to avoid the bright lights…

A Note on Agile and Lean

Agile and Lean help. The Agile and Lean models are process structures which help us model fundamentally creative and fluid business of building software. By emphasizing that software isn’t done until it’s done, that iteration is a fundamental methodology, not a bug in development, and that the sooner software is exposed to real use the better (among many other things), these frameworks more closely match how people express themselves in code. (And it’s worth reminding ourselves that a software project is only that: people expressing themselves in code).

But all frameworks can be hot-wired. The definition of “done” can be fungible. Features that are “hard” can mysteriously end up way down the story list. Judgement, management and leadership still apply. Finishing is still hard.

Getting Finished — Management

Accomplishing anything worth doing with a group of people meansmanaging: tracking details, setting deadlines, assigning tasks — building and checking off lists. Finishing a software project means lists. Long lists.

There’s no real magic here. Your job is to hold the truth up to the light, and that means you just have to track everything: the truth is in the details. All of them.

Everything. Bugs, issues, opinions, performance, you name it. Anything you don’t track will be incomplete or dropped. Could be you’ll get away with it, but eventually the habit of producing incomplete results will catch up with you and your team. There are plenty of tools for tracking, and entire books on how to do it well. Find one, and do it.

It will feel like overkill to track every single thing. It’s not. It will perhaps feel overwhelming. You may feel you are being unreasonably stubborn, or too detailed. You’re not. You are providing a vital service to your team to help them achieve the difficult and rewarding task of finishing something difficult.

Eventually the lists will start shrinking rather than growing. And you will be close to being finished.

Getting Finished — Leadership

So you’re managing. You’re also leading. Your role is to provide the energy to help your team through the barrier of not wanting to see where things stand — to see that yes, you’re not finished yet but you will be.

Your leadership role is to have courage and confidence that what you’re building will work, and that each detail, bug and nasty little issue taken care of is a step towards finishing. Really finishing.

So you celebrate wins. You celebrate finding bugs. You dig mercilessly into performance reports. You ask questions about quality levels. You show progress daily, weekly and monthly, and you let your people know what yes, it’ll be finished, and yes, it’ll be great. You know that, right? No? Well, what do you need to fix?

Finishing Is How You Leave Your (And Your Team’s) Mark

Pieces of software I had a hand in building over twenty years ago are still being used by thousands of people (hi, FrameMaker!). Projects that I thought at the time would kill me and the people working for me helped allow our company to go public (hello — and goodbye — Director). I love the fact that we built them. I love that people are still, to this day, working in careers that are possible because of them. The act of actually finishing them? Hard! Unfun. Not sure I loved it, but all of that intensity was necessary to bring them into the world, and I’m glad they are there. They are parts of my mark in the world.

Finishing a challenging, creative task is one of the harder things human beings can do. We are wrestling something out of the realm of thoughts and ideas into the real world. We have to see, and come to terms, with all of it — every detail, every flaw. To do that requires a constant focused, concentrated effort.

If you are leading software people, your job is to help your team get into that uncomfortably intense pocket of growth.

And then you’ll be done. And you will have added something to the world, something that you, and the people that work with you, have created.

Posted by: lrrp | December 4, 2017

When to Switch to Microservices

With the rise of microservice architecture in the past couple of years, many developers find themselves wondering if it’s right for them. There are two frequently asked questions I’ve seen concerning microservices:

  1. Should I switch to utilizing microservices?
  2. When and how should I switch to microservices?

Should You Switch?

The focal point of whether to change your architecture can often be productivity.

Productivity drives developer happiness. When developers are productive and able to make the changes they want, things are good. In an ideal world, programmers would be less concerned about implementing a feature than designing it. The goal ultimately is that we design more than we code.

The problem with all of this is that our applications become harder to change as they grow in size and age. Technical debt starts to pile up and bring productivity to a crawl. What were once considered arbitrary changes then become six-to-eight-hour rabbit holes of trying to understand why a change doesn’t work.

Eventually productivity hits such a snag that something has to be done about it. This is the point where microservices start to appeal to many teams. They offer what looks and seems like a welcome change of pace.

However, microservices are not a short-term bet. They’re a long-term investment.

Neither are microservices a total solution to developer productivity. In fact, they change your team’s entire workflow, skill needs, and way of thinking. The early days of implementing microservices for your projects will likely be full of the trashing and troubleshooting you’re trying to avoid. However, this short-term annoyance should eventually usher back the productivity and organization your team is after.

I’ve learned that teams that are sizing up the switch to microservices should ask themselves a few questions:

Do we want to make a long-term investment in our application architecture?

Are you planning on eventually sunsetting your application? Think three to five years into the future on this one.

Are we feeling limited by a language subset in our application suite?

Do you feel limited by a language’s speed or tooling? We often tout about how a certain language is faster, cleaner, more usable than our current stack. Yet, what would it actually look like if you could write a service in a “better” language? Would the concept appeal to you and your team?

Are we wanting to invest more in serverless services?

Serverless services are a trend with microservices where we delegate certain parts of our architecture to a third-party service. Utilizing serverless services like AWS Lambda could be a really helpful means for your team to start writing microservices.

Are our engineers willing to share problems and issues across different services?

Most small teams have to be able to hand off microservices issues and bugs to one another. You have to be willing to spread out the knowledge base and understanding, perhaps a whole lot more than you’re used to.

Let’s assume you finally decide that you want to pursue microservices, but there’s still a question lingering in your team strategy: “When and how should we switch our architecture?”

When and How Should You Switch?

The truth is there’s no perfect time to switch to microservices. However, there are a few important considerations you can put in place beforehand to try to make the transition smoother:

  1. Cut down on feature churn and refine the product you want to decompose into microservices.
  2. Commit to a certain stack of languages and tools.
  3. Establish, at least generally, the product’s design as a microservice.

I can’t express how difficult it is to convert a constantly changing application into microservices. If you don’t have a core product to decompose and refine, you’re going to be doing a lot of redundant changes to your services instead of making them more stable.

Committing to a certain language and/or stack is a bit harder in practice than theory. Many companies will tell you that they use a certain set of languages and frameworks, and they certainly might. However, there’s always a crisis at hand as to whether to keep or move on from a certain element of it. Being committed to a certain stack (at least for the time of transition) makes it a lot easier to decompose. You can certainly try to risk a new technology or idea on a microservice. However, you’ll be wrestling with the cost of integrating something new as well as a new architecture type.

Have an idea of what you’re trying to decompose into. Try to cut down on the tendency to wing it and change it later just because it’s a smaller service now. Microservices work best when they’re modular but also well-defined.

Digesting It All

While it might be easy to think of our applications as soulless digital machines, I’m becoming more convinced we should treat them as our homes. We want to make our codebases warm and inviting to anyone and everyone who encounters it. Does your house have the space for careful organization, for example? Does it give you the ability to only allow specific things in each room?

With microservices, we have to have a preference for that level of organization, and we need the ability to implement that sort of separation. Yet you also have to want to have a finer separation of concerns between each part. If that idea resonates with you and your team, then maybe it’s worth looking into.

The transition isn’t easy. However, it could lead to a much more organized and long-lasting codebase at your company.

Posted by: lrrp | November 28, 2017


Posted by: lrrp | October 15, 2017

Never Stop working on yourself…..

Posted by: lrrp | October 15, 2017

The software engineering notebook

Fellow software engineers/hackers/devs/code gardeners, do you keep a notebook (digital or plain dead-tree version) to record things you learn?

Since my days assembling glassware and synthesizing various chemicals in the organic chemistry lab, I’ve found keeping notes to be an indispensable tool at getting better and remembering important lessons learned. One of my professors recommended writing down, after every lab sessions, what had been accomplished and what needed to be done next time. When lab sessions are few and far apart (weekly instead of daily), it is easy to forget the details (for example, the mistakes that were made during weighing of chemicals ). A good quick summary helps with this!

When I first started working for a software company, I was overwhelmed. Academic software development was indeed very different to large scale distributed software development. For example, the academic software I wrote was rarely version controlled and had few tests. I had never heard of a ‘build’ or DEV/QA/PROD environments, not to mention things like Gradle or Jenkins. The academic software I worked on was distributed in zip files and usually edited by only one person (usually the original author). The systems I started working on were simultaneously developed by tens of developers across the globe.

To deal with the newbie developer info-flood, I went back to the concept of a ‘software engineering lab notebook’. At first, I jotted down commands needed to setup proper compilation flags for the dev environment and how to run the build locally to debug errors. A bit later, I started jotting down diagrams of the internals of the systems I was working on and summaries of code snippets that I had found particularly thorny to understand. Sometimes these notes proved indispensable in under-stress debug scenarios when I needed to quickly revisit what was happening in a particular area of the codebase without the luxury of a long debug.

In addition to keeping a record of things that can make your development and debug life easier, a software engineering lab notebook can serve as a good way to learn from previous mistakes. When I revisit some of the code I wrote a year ago or even a few months ago, I often cringe. It’s the same feeling as when you read a draft of a hastily written essay or work of fiction and then approach it again with fresh eyes. All of the great ideas suddenly seem – well- less than great. For example, recently I was looking at a server side process that I wrote to perform computations on a stream of events (coming via ZeroMQ connection from another server ) and saw that for some reason I had included a logging functionality that looped through every single item in an update (potentially 100s ) and wrote a log statement with the data! Had the rate of events been higher, this could have caused some performance issues, though the exact quantification of the impact still remains an area where I need to improve. Things such as these go into the notebook to the ‘avoid-in-the-future-list’.

Posted by: lrrp | October 14, 2017

Do You Have ‘Self-Taught’ Imposter Syndrome?

In a world where devs are increasingly self-taught, it may be easy to negatively compare yourself to those colleagues who have a BS or MS in Computer Science. But don’t.

A lot of you are brilliant, and you don’t know it. It saddens me to see such wasted potential in those that think they are not good enough but in fact are amazing and often 10 times better than those that think highly of themselves. These people, not all of them, but some, I feel suffer from imposter syndrome.

I will do my best to explain my experiences with this mental state of mind and how I’m currently battling with it. Once you understand what imposter syndrome means, and a read a real life example, I hope you get some mental clarity.

Always Planning: Procrastination

Once you see what I’m talking about you will understand the importance of taken action instead of planning. This is the only cure for “imposter syndrome.” Allow me to explain.

What Exactly Is Imposter Syndrome?

By its very definition, it is a concept describing high-achieving individuals who are marked by an inability to internalize their accomplishments and a persistent fear of being exposed as a “fraud.”

Let me start with my personal experience. I know I’m good at what I do. But often times, I get the fear that I’m not as good as the teacher or that I should not do it because it’s already been done. I believe this has been established since I have been on my own. I know I am good enough, and I know I can get it done. But the feeling that I don’t deserve what I have persists.

Imposter Syndrome: The Roots I’m Seeing

Learning in isolation and being self-taught leaves you (typically) to hold yourself accountable. Whereas in college and other team-based learning environments, you have a team or classmates to compare and be held accountable against. The lack of accountability while learning (no bad grades here) sets an unvalidated tone in our society. You didn’t go to school, why should you be trusted? Other forms of validation are also, in my opinion, critical to our success, but understanding which ones to seek makes the difference.

It is important to understand that not being validated is something a lot of people fear in their careers. Being validated means you have the skills or you are “valued” for your achievements. The misconceptions of what validation truly is versus what it is believed to be is the number one thing that holds people back from excelling in their careers and life in general.

Getting the Right Validation

What Is the Wrong Kind Validation to Seek?

The desire to please everyone. Negative, unconstructive opinions and thoughts of you mean absolutely nothing. Get that into your head. If someone doesn’t provide feedback that helps you grow, it isn’t worth accepting. Do not take invalidation from negative peers, take validation from your works and knowing you did your best and always working towards improving.

The piece of paper. – The internet has changed the way we learn by several orders of magnitude. It has lifted us to new heights and has made us excel in research and innovation. This has left some developers who are self-taught without the ability to land high paying gigs in the corporate world. The need for a bachelor’s degree continues, when, in all reality, the real world experience that we have implemented by far exceeds the value of the 4-year computer science degree. Real world experience always triumphs unused knowledge. Don’t get me wrong – having a degree is fantastic! But it shouldn’t be a huge variable in today’s world.

Please don’t let not having a degree bother you. If you are self-taught, you have a lot of skills that many others don’t. It takes self-discipline to sit down and do research in order to learn a new craft. You have to take pride in that. Never undervalue the education you are presented with, even if it’s an education you gave yourself at your own pace.

Where Should You Find Validation?

The answer should be your work. Your work is your validation. At the end of the day, when you lay your head down, your projects, your art, whatever it is you have tossed out into the world is your validation. It shows, “Hey I can do this. I did this. Look here it is.” Hopefully, people will see what you can do and hopefully want to work with you or encourage you in a positive and motivating way.

Improve Daily – Remind Yourself Who You Are!

You have to tell yourself nearly every day that you are good enough. That you have the ability to succeed as long as you put time and energy into your goals. That you will succeed and that there is only one person who could stop you. Yourself.

Keep this in mind: I have to hold myself accountable for all my work. Only I can change my direction. Each day I wait is a day I get behind. I will move forward. I will succeed, and I will establish myself in the areas of my expertise. I will grow every day. I will do something unique to find new people and opportunities. I will not fail. I will never give up. I will always do my best to complete what I put my blood, sweat, and tears into. I will not be scared to hear the word ‘No’ and I will not be afraid to overcome it either.

How to Over Come Imposter Syndrome

One word, execute. I have noticed that when I have the most down time is when the imposter syndrome kicks in. I don’t think I’m good enough. I question life choices. If I’m executing, doing something productive, like writing this blog, then I’m doing something to put something out into the world which serves as my validation. Some people will read this, some will share. Others may not even get past the first sentence. But it is okay. The ones that reach the end are all that matters.

You have built your own success – remember that.

Posted by: lrrp | October 8, 2017

Microservices Communication: Eureka Client

Eureka! No more need to store service URLs in code properties and update them with every change. Service discovery with Eureka will solve the problem for us.

In the previous Java microservices tutorial example, I created a Eureka Server. In this tutorial, I will show you how microservice communication happens. In this tutorial, I will create a Eureka client that communicates with a Eureka server — a microservices service registry.

Before diving into the code, let me tell you more about the about Eureka’s client/server communication.

Eureka Client/Server Communication

Talk to the Eureka server: At first, while the Eureka client is bootstrapped, it tries to talk with the Eureka server in the same Zone. So, suppose a Eureka client instance is in the Asia Zone —  it tries to connect to the Asia Zone’s Eureka server. If it is not available, then it fails over to another Zone.

It determines its targets using the eureka.client.serviceUrl.defaultZone property, so we need to give a URL of the same Zone’s Eureka server. And for failing over to another Zone, the Eureka server should be peer connected.

Register: Next, the Eureka client/microservices share the instance information with the Eureka server and registers themselves with the {service-id } (

Heartbeat: After registration is successful, after every 30 seconds, the Eureka client sends a heartbeat to the Eureka server to renew its leases. So, if after 90 seconds the Eureka server does not get any heartbeat from the Eureka client, it unregisters the Eureka client instance from the service registry and sends the updated registry to all peers and Eureka clients.

Fetching service registry: Eureka clients fetch the service registry from the Eureka server so it can discover other services and communicate with them. After every 30 seconds, this service registry information gets updated by receiving delta updates from the Eureka server. Please note that the Eureka server also caches the delta updates every 3 minutes, so the Eureka client can receive the same delta instances multiple times. After receiving delta updates, it again tries to compare its local registry with the server registry to check that delta is successfully applied. If there are any mismatches, it pulls all the registries again.

Unregister: When the client instances are going to shut down, they send a cancel signal to the Eureka client so the Eureka server unregisters it from its registry.

Synchronization: Be aware that there may be some time lag as the Eureka server and client manage the cache.

Coding Time:

We will make the EmployeeSearchService a Eureka client. To do that, first, we need to add the discovery module for Spring Boot in the Maven pom.xml.


Now add the @EnableDiscoveryClient annotation on top of

package com.example.EmployeeSerachService;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
public class EmployeeSearchServiceApplication {
   public static void main(String[] args) {, args);
After that, run the Eureka server first, then EmployeeSearchApplication. You will see that the Employee Search application is registered in the Eureka server with the service id EmployeeSearchService.

Older Posts »