Forem: ᴋᴇᴠɪɴ ᴘᴏsᴛᴏɴ

IPAT - A New Principle I'm Following

ᴋᴇᴠɪɴ ᴘᴏsᴛᴏɴ — Mon, 06 Dec 2021 20:30:44 +0000

One of my least favorite code review comments to give or receive is

"This is great, but we already have code to do this over here..."

Don't get me wrong, I'm glad the comment happened when it did. It is better than never getting it, but think about the time that was just lost. 😱

As the reviewer, I treat this as a smell. What can we do better to make this reusable code more obvious?

Better documentation?
Better use of well known patterns?

As the author, I feel lazy. How did I miss that we already do this?

I am new to my current codebase, and I have had this happen a few times already. I knew the codebase at my previous company like the back of my hand. I would tell new folks to assume the code you need to write is already there. Sometimes it is true, sometimes not. But it was a healthy assumption that saved them time and cut down on unwanted duplication.

Need to write a new test helper for your situation? It's probably already there. Need to sanitize these params in a certain fashion? It's probably already there. Need to do [insert some complex domain thing]? It's probably already there.

I'd like to introduce a new principle that I'm going to start using more often.

IPAT - It's probably already there.

One of the largest detractors to a maintainable code base is duplication. It's also one of the most frustrating things for new folks.

"Uh, which one of these ways is the right way?"

Having this principle of IPAT on the mind helps reduce adding yet another way to do the same thing. It also gives you a reason to search through the code base more, which as a noob, you learn to appreciate.

If we are being honest, we should be doing this already, and most of you probably already do. But I suppose that's the point of principle mnemonics right? They help us to remember things that usually serve us well.

For the well actually crowd...

Isn't this the same as DRY?

No. The DRY principle is one to consider when you are about to knowingly duplicate code. IPAT is about assuming what you need is out there somewhere so that you don't mistakenly duplicate. For another blog post, but there are absolutely reasons to repeat code.

Isn't this the same concept as "Don't reinvent the wheel?"

Yeah, kind of. But I like IPAT a lot more that DRTW. 🤷‍♂️

Creating Blue Chip Devs

ᴋᴇᴠɪɴ ᴘᴏsᴛᴏɴ — Fri, 05 Oct 2018 03:12:51 +0000

Blue-chip stocks have a reputation for being proven, experienced, well-known and dependable. Penny stocks also have a reputation, characterized as speculative, risky and cheap.

If you want a stable financial future, it’s obvious that you would purchase as many blue-chip stocks as possible. Simple, right? Unfortunately, blue-chip stocks are expensive and not plentiful; they are the best of the best. How can you maximize your financial well-being if you can’t seem to find affordable blue-chip stocks, and can’t trust penny stocks?

The technology industry, and the firms within, have a similar predicament with experienced vs. junior talent. Many tech firms forget that penny stocks (junior talent) exist and spend all of their time and resources trying to find the right blue-chip stock (experienced talent). Whether looking for the best stocks – or technical talent – many firms will go as far as hiring someone to scout the perfect blue chip for them. After a while they come to the realization that you can’t always find that perfect blue chip, thus leaving them to settle for a few penny stocks and hope for the best.

Hoping for the Best is NOT a Strategy

Hope for the best. That’s not exactly what most people want to do about the future of their finances or their company. The technology industry should not be settling for a “hope for the best” strategy either.

If we in the tech industry want to solve the shortage of blue chips, then we must invest in pennies with experiential learning and mentoring programs. The influx of blue-chip developers will not just appear one day; the movement must be built, and we are the ones that must build it.

No Magic Bullet

In order for a junior developer to be dependable, they need opportunities to show that they can be depended upon. Opportunities alone, however, are not enough to create blue-chip developers. Some companies may subscribe to what is called the “10,000-hour rule”, which states anyone can master a concept after practicing it for 10,000 hours. Furthermore, many tech companies practice this philosophy without even realizing it. The rule proposes that, by exposing junior developers into project after project, they will increase their skills by doing the same thing routinely. If a developer works eight hours a day, five days a week, it would take them well over four-and-a-half years to reach that magic 10,000-hour mark.

Technology experience doesn’t just include the length of your career, or the hours that you have spent writing code, but rather the content that fills those hours. Being strategic with a junior developer’s career growth is crucial for quickly turning them into experienced developers.

Seek Out Opportunities to Grow Your Investment

Experts should always be looking for opportunities to teach. Though some will say they just don’t have the patience to teach, those same folks need to realize that their impatience might not be due to the failure of the student, but rather their own inability to properly communicate the concept. Some have said that the only way to know if you truly understand a concept is through teaching it to someone else. Teaching is a skill not often discussed in software development, and not many developers include it on a resume, but I would argue it is one of the most needed skills for senior developers. Naming design patterns is great, but being able to properly communicate what they do and when they should be applied is really what matters.

Deliberate practice with junior developers can happen in many forms and there is a lot of free material available to help. Code katas like The Bowling Game are great for coding practice. Katas teach core concepts of software development and are very easy to repeat.

Everyday development tasks also fall under the concept of deliberate practice. Bug fixes are great for pairing sessions between juniors and experts. The expert can shine a light on why the bug was introduced and add some key takeaways for avoiding similar bugs in the future.

Don’t be a company that just hopes for the best; be a company that strategically invests in junior developers. Take the time to fill every hour of their development with impactful experiences. Imagine how fast the next generation of developers will level up if they learn from the mistakes that we have made over the years. We can see developers writing dependable and maintainable code well before 10,000 hours; we can turn penny stocks into blue chips.

This post was part of a series: Increase your stock by investing in your future

What To Do When You Don't Know What To Do

ᴋᴇᴠɪɴ ᴘᴏsᴛᴏɴ — Fri, 21 Sep 2018 03:00:18 +0000

Getting into a nice flow is one of the greatest feelings as a developer. You put your headphones on and get lost in the code. Hours tick by as though they are minutes and you just enjoy the thrill of making the computer work for you. Features and bug-fixes are being crossed off left and right and at the end of the day, you marvel at your ability to make something happen out of nothing. You are awesome.

And then there are days when you can't get something to work, and you wonder how you even got hired.

It happens, and it happens to everyone. Everyone comes up against situations where they exhaust all their brain power and google-fu only to become more frustrated that they cannot figure it out. You are not alone.

So what do you do? You figure it out, that's what. You are a developer, solving problems is what you do!

Here are a few things I try to keep in mind:

1) Code Only Does What It Is Told To Do
When your code is doing something that it should not be doing, remember that you (or some other library or package you are using) told it to do that. Being able to debug your code is such a vital skill that a lot of developers take for granted. When I'm working on a complicated problem, I'll log everything I can so that I can make sure I know the state of my code at all times. Somewhere, someone has told the code to do the thing you think it shouldn't. You just have to find that somewhere.

2) Don't Assume Anything
I love it when someone asks me over to their desk to help look at a problem with them, and while explaining the problem they find the solution. This is a well known phenomenon in software engineering called rubber ducking. This works so often due to the fact that it forces you to prove your assumptions. Always go back through the scenario and make sure that everything you think to be a fact, is actually a fact. Don't trust that the name of the method or function is enough to give you the insight you need. Go see exactly what that function or method is actually doing.

3) Understand Your Integrations
Some of the more complicated issues I've encountered were a result of trying to integrate my code with another package or library. I know, you expect that thing to work like it says it should, but guess what? Mistake-prone humans much like you and me wrote that code, and no software is completely bug-free. Don't be afraid to go look at their code to see exactly what is happening. Sometimes you'll find that the issue wasn't in your code, it was in theirs! Next thing you know you are submitting a PR and contributing to the community. Which not only fixes your problem, but think of all the other developers that will never have to feel this pain because of your help.

4) Get a Fresh Perspective
Sometimes you need to step away for a while and let your brilliant subconscious figure out the problem for you. This happens all the time. Other times a fresh perspective means that you bring in someone else. Don't feel defeated when asking others for help. Software is complicated. Even the most simple bugs sometimes can slip through the cracks because well, let's face it, we are not robots. We are not perfect. So don't be ashamed to bring someone else over. It doesn't mean that you aren't capable of figuring this out. You have the maturity to realize that there is something that you are missing, and maybe someone else can find that something.

If none of these help, then I'd find a different profession. Totally kidding! These are just a few things that help me, and I hope they help you as well!