The "Genius" Developer

David Joseph Kamer — Wed, 09 Oct 2019 19:32:24 +0000

You don't have to be a genius to develop software. Dev isn't about reinventing the wheel, even if it's fun. Just like almost everything else in life, there's a difference between what you want to do and what you should do.

Let's reinvent JSON.parse

Gene is a fresh out of college Computer Science genius. He knows all of the algorithms that any undergrad degree holder in Computer Science could ever be taught, plus a few more that he studies in his free time. Studying algorithms makes him feel like a genius, and rightly so. His IQ might be above 160, but that doesn't really matter right now.

Gene is starting his first job as a JavaScript developer. He's never really "done" JavaScript before, but how can it be that much different from his C and Assembly code? He thoroughly studied both in school. He knows the difference between a bubble sort and a quick sort, how difficult can JavaScript be? It's not even a real language after all.

Gene's first task on his first day is to make an ajax request to the company's API. Most of the code is already written. The senior developer, a college drop out who attended a coding boot camp, just copied some boiler plate from a previous project to help Gene get started.

Gene cracks his knuckles, looks at the code, and sees it print out

"{"foo": "bar"}"

in the console. Whoa, this is super easy. Now he just needs to store this in a JavaScript "Object". He thinks to himself how silly JavaScript is to have so few data structures. Piece of cake, he just needs to parse the string using a few regular expressions, and then recursively add the keys and values into an "Object".

8 hours after reinventing JSON.parse

Gene stretches and yawns. He's done. The work day is over. No longer will the object "{"foo": "bar"}" remain unparsed. He clocks out, feeling validated in his genius. "Pah! JavaScript, more like EasyScript!" His confidence reassures his fellow office workers that a real genius now works with them.

2 days after reinventing JSON.parse

Gene is called into his manager's office. He's mostly been in meetings over the last few days, reassuring everyone that he really is smart by talking about algorithms. The senior developer is sitting in manager's office. The manager closes the door behind Gene as he sits down. They both hold a somber expression, with the senior developer mixing in a unique blend of petulance and contempt.

Gene asks, "What's all this about?"

The manager responds, "Wait a second, we need to wait for HR."

The senior developer sneers and then hides it.

Karen from HR enters the room with a saccharine presence, "Sorry to keep you waiting! Let's begin."

Over the next hour the senior and the manager explain to Gene how his code has cost the company several million dollars. The code he wrote only parsed the key and value on the first layer of an object. After all, he only wrote it to parse "{"foo":"bar"}". The result was an endpoint that sold items for "[object Object]" dollars. Now this isn't only Gene's fault. "Why the hell is '[object Object]' considered 0?" Gene protested, but the protest didn't matter to the HR department, and the senor developer knew why and just smiled. He knew that the last genius they hired had crashed the whole system with an invalid type, he got the blame, and he added a default case.

HR didn't like that Gene said he knew JavaScript like the back of his hand on his resume and in his interview.

Gene was fired.

Gene went home and googled "parse JSON with JavaScript", found that JSON stood for JavaScript Object Notation, that there was a built in tool called JSON.parse, and then proceeded to cry himself to sleep.

Don’t Get Mad, Get 2 % 2 === O

David Joseph Kamer — Mon, 07 Oct 2019 21:19:21 +0000

Coding can get frustrating.

Frustration is something you can control, but it can be a hard sell when you’re facing numerous deadlines–and your code isn’t doing exactly what you expect. Your hopelessness can easily increase when you search for solutions.

Searches can end a few different ways. One way is you find your answer. Usually, in this case, it’s something you’ll feel is obvious after you see the answer. There are rare cases where it’s “re-initializing the quantum field generator” or something equally ridiculous, but we’re on the topic of problems that boil your blood.

Another way your search could end resembles the path a bad ARG (Alternate Reality Game) would take. You find clues to your answer, like it’s a scavenger hunt, but you never really find an answer that makes any sense for your current problem. Congratulations, you’ve either found a problem that no one has ever encountered, or you’ve found a problem that no one felt the need to share the solution to. If it’s the first you might be working on something ground breaking (or hacky), and if it’s the second you might be working on something that only 1337 coders can solve (definitely something hacky).

So now you have to solve your own problem. But you’re a smart dev, right? You obviously only searched the problem because it’s really technical and not something that requires your problem solving skills, right? Wrong, you searched it because it’s easy to solve 99% of the low hanging fruit that way, but you’ve now stumbled on either 1% of the low hanging fruit or a problem that, shockingly, actually takes some knowledge and experience.

Now, experience is sort of a chicken and egg thing. You can’t have experience without building up experience, and you don’t build experience by showing up to work. This isn’t an RPG where you can left click on something and your XP magically accumulates. No, you gain experience by doing the things that are difficult.

Your brain probably already knows this. You may even tell yourself this. But remember, you’re working against several deadlines and the clock is ticking. So what does your instinct tell you about this problem that has recently gained the categorical label “stupid”? It tells you to call the problem “stupid” and throw your coffee cup out the window.

Don’t do that.

I mean if you have to it’s better than posting edgy things online or mean comments on a YouTube video.

Anyway, anger isn’t the answer. Now don’t think the opposite is the answer either. Don’t start playing a violin as the ship sinks. Don’t get defeated. The reason you are a programmer is because you solve problems. These type of obstacles are what should get you out of bed in the morning.

If you feel defeated or if you feel angry, even after reminding yourself that you shouldn’t, don’t feel dissuaded. You can’t just flip a switch on your anger. Take a step back from the problem. Go read a book or take a walk if you have to. If you’re having a hard time controlling your emotions, maybe check out some Stoicism or something Zen, but right now, in the short term, just check out if you have to. Now when you’re not feeling angry and your vision is clear, don’t approach the problem directly.

David Wheeler – “All problems in computer science can be solved by another level of indirection”

Now this quote means something not directly relevant to your coding practices (sticking with the spirit of indirection), but it’s still relevant to what I’m about to tell you. You need to look at your code. Don’t look for your problem, go fix up your code. Look for all the possible errors and bad practices. Think about it, if you fix all of the errors and all of the bad practices, you indirectly fix the error that is blocking you.

You – “Jeez, thanks, I guess I’ll just go fix all the errors now, some help”

No, It’s not about fixing all the errors, it’s about widening your perspective. Don’t beat your head against the wall. Use your brain to make the code better. Odds are the problem isn’t a problem you’re naturally going to see. After all, you would have already found it if you’re (already) wired in a way to do so. As you move through your code, you’ll get a better idea of how it works as opposed to how you intended it to work. You’ll learn quite a bit about yourself and the mindset you had when you wrote the code.

Marcus Aurelius – “Waste no more time arguing what a good person should be. Be one.”

When you approach your code with the right attitude, you’ll stop arguing with yourself (and the wonderful people over on StackOverflow) about how to do it, and you’ll just get it done. You’ll see your own errors and you’ll fix them. Anger is no longer an issue when you realize what’s in your control, and you avoid worrying about what’s not in your control. Don’t worry, just fix your code—all of it.

Also, did you catch the error in the title?

DEV Community: David Joseph Kamer

The "Genius" Developer

Let's reinvent JSON.parse

8 hours after reinventing JSON.parse

2 days after reinventing JSON.parse

Don’t Get Mad, Get 2 % 2 === O