DEV Community: Doug Kerzner

Decisions Back To Front

Doug Kerzner — Wed, 21 Apr 2021 17:15:28 +0000

When and where I like to manipulate my data:

Building out a web application from the ground up comes with making many decisions. A good portion of these decisions will be about where you are going to implement your code. These choices are not always clear, many times I also find the way I thought was the path turned out to clearly not be.

Another huge resource for me is my maps. My ERD, flowchart, UX journey, and anything else I can draw out in my prep stages will prove invaluable during development. We're moving data back to front longitudinally first, after that data is delivered into the front end we're then moving it latitudinally between react components. The way I like to think about it is my databases, and that data being sent to the front, is an East-West movement, once I have my data in React I'm then moving it North-South.

Keep in mind, even the most organized and planned out individuals will run into these issues. Just as we dev's are told to embrace bugs and errors, we also need to embrace flexibility in stride. Well thought out changes will have to be made on the fly and implemented immediately, it's the nature of the biz. There will also be situations where you won't fully know if a decision will 100% work out until you're in the thick of it coding Being organized will help you make a pivoting decision easier because you will have a path

Some questions I like to ask myself when deciding between front-end & back-end:

Some things to consider:

What models am I picking data from? Do these models have associations? Can I use the associations for my benefit?

Am I doing anything with my data after I fetch it?

If I'm taking a large chunk of data into my front end and then parsing that down in the front end, is there a more efficient way to get it done? Back-end iteration is generally easier in my limited dev experience. Can my backend trim the fat off of my data before it's packaged and sent to the front? Many cases this will be true. If you're looking for a specific set of info ready to render in the front-end without doing anything else, back end iteration is the way to go.

Can State solve some of my problems?

State solves many of my issues in the front end. If I'm not persisting my data back to my database, I can probably do a single fetch request to get what I need and then keep that data stored in state to be shared and passed to the child components that need to use it.

Can a serializer help with my issue?

A good understanding of serializers can help you greatly. Instead of making multiple fetches to get data from multiple models, you can use your serializer to package associated data from multiple models delivered in a single fetch. Once the data is moved into the front-end I can iterate over it and pull out the info I want to use.

What am I doing with the data on the front end?

Sort of a loaded question in & of itself. Of course we're doing something with it, but its specific use will be important in dictating your approach. Pseudo it out! Write out in the simplest terms what you want to do with the data you've got in your hands.

There will always be many different approaches to how you can solve a problem. I hope sharing my thought process may shed some new light or offer a different route to take when tackling your application. Be transparent about your inner thoughts and share it with others, you'll be surprised how much you'll learn and how you'll also realize you're not alone in your struggles.

My approach to debugging:

Doug Kerzner — Thu, 01 Apr 2021 17:58:43 +0000

Computer languages share many similarities while still being completely different from one another. Syntax varies greatly, as does the way variables are declared, in some languages you have to worry about scope, other's not so much. There is one thing though that all languages share, errors. Although all languages will kick back an error when something is off, not all errors share the same details. In Ruby, errors are extremely forgiving, they do a very good job at explaining what, and where things went wrong. Javascript's errors or not as kind, they don't assume the way Ruby does, making things a little harder to debug when inevitability strikes.

I'd like to share my though process, questions I ask myself, and approach on how I tackle any errors to debug:

Remember Your Training:

You started your journey into development by learning and studying the particular language you're writing. During this process you should have run into tons of errors. I'd like to say this is part of the developing growing pains, but in reality, errors are here to stay and are your friends, embrace them! Try to think about what the most common errors you received during your learning process. This is a great place to start, go over all the common errors you're used to getting back. You can start crossing them off of your debugging list and move on to the next step of debugging.

Think About Your Own Scope:

You should be working on your project in pieces and pushing to Git frequently! Some good questions to ask yourself: What code was working before the problem occurred? Do you have a previous working Git commit to compare with? Where in your code is it breaking and if you can tell, what block is causing it to break? Narrow down where it's occurring.

Weed Out The Necessary Info From The Error:

Many errors will kick back a ton of information, a good amount of this information will point to folders you haven't even been working in. There are situations where these folders being pointed to will be relevant, they have been few and far between for me. Learning to trim the fat off of these error messages will help cut down your debugging time. Most of the time the most important part of you error messages will point to a folder or block of code that you've written in your program.

Location, Location, Location:

While your error may not say explicitly what the problem is, it generally will point to where it's occurring or bring you very close to where it is happening. Some things to keep in mind, is your code that is breaking interacting with other code? i.e. Is it breaking in the front end while doing something with the back end (or the reverse)? Follow all the routes your code is taking and analyze every place it's making something happen, it is possible a backend problem is causing an error code in the front. Be mindful of this, maybe leave yourself some breadcrumb comments that points to what backend block is interacting with a frontend block.

Use The Tools Available To You:

Just about all languages come with some form of a debugger. Do yourself a favor and get acquainted with it early and often as it will be your best friend at times. Whether it's pry, byebug, or tools made available to you through Chrome's dev tools, be aware there are helpers out there to allow you to stop your execution and for a moment live inside the block giving you problems where you can call and run code related directly to where you stopped your program.

The Great Google:

The good news: the error you've run into has happened millions of times to other people and has been solved. The information on how to fix this is already on the web, waiting for you to come across it and have it help you.

The bad news: You're having trouble putting exactly what is happening into words when searching. Are you searching your problem in your own words? Did you search the specific error you're getting back?

There's a few things at play here. All coding projects vary greatly in what exactly it is the application is doing, this can make it difficult to apply what you're reading in your error googling to your own code. This is something that will come with doing more. More coding = more errors to read = more articles to google

Check With Your Network:

So you've made it this far, you've tried everything your brain can wrap itself around and you still have not fixed your bug. You've google, tried many different approaches, refactored your code, made a mess of things and still came up empty. Time to swallow your pride and ask an external source to come take a look. Sometimes there's nothing like a fresh set of eyes to look over your code and help. The same way walking away from coding can help bring clarity to a situation, a view from the outside in can help immensely.

Let's face it, bugs are annoying as hell, but they're not going anywhere and are a necessary evil. Embrace the suck, it will build you into a stronger coder. Sifting through bugs in great detail will help you out in the long run. Also, the more you do it the better you will become at it, practice won't make perfect, but it will certainly get you a hell of a lot closer to it.

The Group Thang

Doug Kerzner — Fri, 12 Mar 2021 15:01:20 +0000

Before coding I could never really grasp the idea of a coding language. I've seen code before, it's in English, or at least, most of it seems to be some form of the English language. But you can never fully appreciate the actual language aspects of developing until you try and communicate it to someone else. Talking the talk is a huge and important part of programming that most folks don't realize before diving in to the community.

That is why I am a huge advocate of the group thang. Working in pairs, in groups, even just talking code with someone that knows anything about developing is crucial for a shortened timeline of success. Learning a new language is difficult, especially while doing it out of and beyond your formative years.

Think about it this way, say your native language is English and you want to learn Spanish. It would benefit you best to speak with someone who know's both English and Spanish to help fix your errors, explain things out to you in detail, and to bridge and make connections quickly. Learning a computer language is scarily similar to learning human language. When thinking about it in a general sense, what are the best ways to practice language skills?

Read it, look at as many snippets and examples in context. Reading what you know repeatedly will help it stick. Are you stuck on your code, or just sick of looking at the same stuff for hours on end? Go and look at someone else's code during a break in your work, certain snippets will jump out at you and get your mind working and naturally inquiring.

Write it, nothing can help you practice more than simply writing and rewriting. Writing will reinforce and cement in your mind what you've retained, helping you add new material on top of it. We don't write human language without any reason, we have context, logic, we write with purpose and understanding.

And lastly the one thing that I believe many miss. . .

Speak it. I cannot stress enough the importance of simply speaking the particular language with others that either understand it, or who are learning it with you. This will get you help you quickly level up. Articulating code to others forces you to understand the concepts you are trying to communicate to others. The people you talk with should also constructively correct you if you've misspoken and help limit repeated mistakes.

As a native New Yorker, I'm sure most folks from here would agree that when speaking with someone you don't know, you could conclude fairly quickly if they are born and raised New York. Aside from speaking a language learned in a classroom, which is generally very structured and proper, us humans like to shorten and abbreviate any which way we can. Slang exists in all languages, including computer languages and learning slang comes with a lot of context. Acronyms also play a huge role in dev languages, knowing and understanding these is a great asset . It also shows you're part of the community, because you're speaking in a dialect that others pick up on and understand immediately, which could, and should, sound like complete gibberish to an outsider.

Working with more than just yourself will really help build these skills quickly and efficiently. I've stressed it before and I'll stress it again communication is so important in programming. The group thang will stimulate these brain muscles constantly throughout this process. Think of normal everyday conversation, asking open ended questions breeds more discussion and dissection of the particular subject you're working on. Questions lead to research which again will introduce you to new syntaxes of the language. It will also introduce you to concepts that are still foreign to you.

Group work will also round you out. Everyone has drastically different strengths and weaknesses. Some are debugging masters, others are syntactical sugarplums, and some may be stronger in associations and relationships. Sharing the burden with others that have a better understanding in certain aspects will help you immensely. It will also streamline getting everyone up to speed in all areas.

So break out your comfort zone! Dive in! Start talking and asking questions about the language you're learning. Work with people you normally wouldn't imagine yourself interacting with, you'd be surprised on how much you could learn from them. It will bring fresh perspectives into your head which is healthy! Seeing another's approach and thought process is priceless.

Coding into the abstract. . .

Doug Kerzner — Wed, 17 Feb 2021 18:52:58 +0000

The Importance Of Fundamentals

and Where It Will Take You

I never got along with school, I couldn't wait to be done with "learning". I began my professional career in sales and quickly found out that learning in all aspects of life NEVER ceases. Whether it be education or training on a new product, learning details about my particular territory, or just being shown the ropes by my elders, learning was not going anywhere. I've also had a habit of challenging learning when given the opportunity, wanting to skip over the boring fundamentals and jump right into the fastest ways to accomplish a particular task, i.e. the fun stuff. Juxtaposing against my own experiences is what helps me understand new material. The subject that most comes to mind is math. This should ring true with most because 99.99% of people learn mathematic fundmentals the same way. Long division written out on paper showing all of the steps done to complete the equation.

Whenever I think about abstract learning, I think about all the math teachers I've had, and the same argument I got myself into that always gave the same answer:

You're not always going to have a calculator in your pocket to do this!!

LIARS!!!

Being someone that would eventually go down the sales rabbit hole and also having a small amount of technological foresight, this argument never sold me on the WHY. Learning the skills to be a developer has certainly given me new found appreciation for my math teachers. It's given me an even greater appreciation for working to get the basics down to second nature as soon as possible. We're not reinventing the wheel when it comes to coding, most of our code is completely unoriginal and will come from multiple sources. Having a strong grasp on the fundamentals gives us the ability to communicate to other what exactly our code is doing 'under the hood.' The strength of this communication is what separates the good from the great.

'Under the hood' counts as a life experience for me to help me learn. I've worked on cars most of my life, I'm not an expert by any means, but I know my way around engines enough to be able to diagnose a problem or follow the paths to bring me to where the problem is. Problems are usually acute in nature, something small that throws a chain reaction to everything that is working properly resulting in a non-working car. The same holds true for coding, tiny details our errors throw combined with fundamental knowledge should bring in the vicinity of the issue to be fixed.

Fundamentals don't just stop at learning either, there's an entire flip side to this coin and that is training, or for someone who plays/played sports should know exactly what I'm talking about:

In sports, the whole point of practice and training is to build muscle memory, you're training your body to react in an instinctive way based on what is presented before you. That is, an immediate recognition or reaction without thought. Our brains are muscles, and if you don't stimulate said muscle skills will diminish.

Learning in theory is abstract in and of itself and that is all well and good. But I ask you, would you rather have a new pilot flying your plane who's only ever been in a simulator, or do you want the one that has thousands of real hours logged in their resume? There is no teacher like experience and all the knowledge you consume should be put into practice, otherwise what's the point? So take the dive! What do you have to lose? You might show weakness of a skill you don't possess to begin with.

It's cliché but I personally subscribe to the 10,000 hour rule to master a particular skill. You have to put the time in to get good at anything. Yes there is always an exception to the rule but if you happen to be one of those exceptions, chances are you won't even be reading this article, or attending a bootcamp to learn this material. Those unfortunates such as myself, will win on effort over raw talent.

The whole point of these ramblings of a mad man is to convey the importance of complete fundamental understanding of coding to be able to keep up and communicate what your code is doing in the background. Programmers are lazy! But you have to attain the pleasure of being lazy, one cannot simply jump right into it. It will take a huge amount of hard work, dedication, and discipline to get yourself where you need to be. Once you're there, laze around and enjoy it, but don't say I never warned you 'learning in all aspects of life NEVER ceases.'