Forem: Nick Karnik

What is the career track at your job?

Nick Karnik — Fri, 23 Aug 2019 18:42:53 +0000

I read an interesting article about Engineering Culture at Shutterstock and the illustration of IC vs Management Career Tracks made me think about how inconsistent it is across the industry.

I've found Levels.fyi to be helpful at shedding some light on the parity of these levels across organizations.

I am curious about what the career track looks like at your job.

Which qualities were exhibited by good managers you've had?

Nick Karnik — Sun, 11 Nov 2018 06:19:29 +0000

It should not be surprising that most people have had more bad managers than good ones. Have you ever had a manager that you considered good? What did this manager do that you found good?

Looking back, here are some of the qualities exhibited by good managers I've had:

They were Subject Matter Experts
Showed compassion & empathy and were down to earth
Treated me like a friend
Mentored and encouraged me to push myself
Stood up for me
Provided honest feedback
Allowed me to be autonomous and did not micro-manage
Helped me when I was stuck & amplified my strengths
Treated every individual's failure as a failure of the team as a whole
Publicly praised and privately criticized

How I Lost My Consulting Job

Nick Karnik — Sat, 27 Oct 2018 00:32:59 +0000

For the past 9 months, I've worked as an independent consultant on gigs that were mostly a few hours long to maybe a couple of weeks. Two months ago, I came across a client providing a service set to disrupt their industry. They were funded in excess of $100 Million.

Landing a stable gig is every independent consultant's dream!

Before I took the gig, the Head of Engineering emphasized two things:

You can work as much as you want. 50 hours, 100 hours, no problem! We have a lot of work.
We want you to know that if you would like to go full-time, the option is on the table.

This prospect was better than others I was about to land because it was a well-funded company with lots of work and going full-time was an option in case I wanted to explore that.

I thought to myself, 50 hours sounds great because I would like to clear some debt and fix some things around the house before our fourth baby arrives. In addition, I wouldn't have to keep looking for work at least for a few months. My family depended on the income from it.

After I signed my contract, I decided to reject a couple of standing offers for long-term gigs. My first week into this job, I was barely able to clock in ten hours of work. I thought maybe this was because both of us needed time to ramp up. The next week, it was ten hours again. Instead of letting that bother me, I decided to enjoy the reduced work hours.

Then, the following week, I barely got to 18 hours. I was told to start mocking up the UI and backend because the backend API's were not ready yet. I mentioned that I was a full-stack engineer and I could work the entire stack, but that was ignored for some reason. In addition, working on their other applications wasn't an option because they wanted me to focus on one.

I was working on a production app, mocking up functionality where parts of the data came in from the production backend and parts from the mock server. Updates were split similarly. This was one of the most convoluted React projects that I've worked on. It used a plethora of React/Redux plugins (very old versions of dependencies that couldn't be upgraded easily) which didn't improve productivity or add value.

All along I was thinking, does $100 million afford a company the ability to be careless with their project? Nothing the application did was groundbreaking. It was clear that the money was raised for marketing.

Somewhere along the line, they assigned a project lead who would ensure my plate was always full. Unfortunately, that person was bound by other constraints and was not able to accomplish that goal. We ended up doing a little bit of pair-programming once in a while which got me another ten hours.

Throughout the project, I was asked if I would like to go full-time. So, I finally had that conversation and during that time also mentioned that I was running out of work-items and I hadn't even crossed 20 hours a week.

Fast forward a week, I was sitting idle for a couple of days, so I decided that it was a good time to follow up on our conversation. I was told that there was no more work because the backend API's would not be ready for several weeks and that they wouldn't consider me for full-time work unless I relocated.

This was unexpected considering the initial conversation. Relocation during the middle of a school year is not an option, let alone with a baby on the way!

What I found really disturbing was the lack of empathy. For the past seven weeks, I mentioned I didn't have enough work and that my family depended on the income from that job, but nothing changed.

A contract doesn't guarantee full-time work!

Anyway, I'm glad that I was able to anticipate this scenario and proactively managed to schedule interviews with the Big Four and a handful of smaller companies. Even though I've been in the industry for so long, I still have to study before interviews, so I'm hoping to be interview ready in the next week.

Over the past two years, I traveled with my wife and three kids for a year through Asia and Europe while I worked on a startup and later worked as a CTO for a couple of companies before deciding to do independent consulting and teaching.

Having worked with close to 200 clients has given me such an incredible experience about the ups and downs of independent consulting. Nevertheless, I feel that I'm ready to go back to work at a stable company. This is something I took for granted and quit two dream jobs in the past.

Regardless of the sequence of events, I am glad that I've tried the things I've felt passionate about. It is evident that I couldn't do that without my wife who supported me in all my decisions.

I've tried to strike a balance between responsibility and following my dreams. Detaching yourself from elements you take for granted makes you appreciate them even more. Events like these are a good learning lesson in case you are complacent.

Changelog: Updates to the comment box

Nick Karnik — Sun, 21 Oct 2018 00:31:37 +0000

Hello DEVs! A few hotkeys are now supported in the comment box. All the commands will accept Ctrl or Cmd as the control key. Also, the character following the control key is case insensitive.

Bold

You can simply highlight text and press Ctrl+B or Cmd+B to make the text bold.

Italic

Similarly, you can highlight a word and press Ctrl+I or Cmd+I to turn the text into italics.

Link

Pressing Ctrl+K or Cmd+K will surround the highlighted text with a link tag and place the cursor on the location where you need to type in the URL. Make sure to prefix it with http(s):// or it turns it into a URL relative to dev.to.

Hotkey to Submit

You can press Ctrl+Enter or Cmd+Enter to submit your comment instead of having to click on the submit button.

I was thinking about adding a hotkey for the image tag, but I'm not sure if there's a universally preferred key combination for it? Please let me know your thoughts in the comments.

You are also welcome to make feature requests or file bugs on the Issue Tracker.

Known issues

IE 8,9,10,11 are not supported.
After using a hotkey in the comment box, the undo functionality in FireFox is a bit flaky. If FF doesn't fix that issue in subsequent releases, we may need to consider integrating a custom history tracker.

Protected Routes in React using React Router

Nick Karnik — Tue, 16 Oct 2018 02:29:15 +0000

In this video, we will learn to create a protected route using React Router. This route is accessible only when the user is logged in.

Link to CodeSandbox
Link to Video on Youtube

If this video was helpful, ❤️ it and subscribe to my YouTube channel.

25:38

React Component Lifecycle Explained

Nick Karnik ・ Aug 14 '18 ・ 1 min read

#react #javascript #webdev #video

Does your employer pay for your health insurance in the US? 🏥

Nick Karnik — Sun, 14 Oct 2018 07:24:10 +0000

Most of us in the US who are in the software profession are lucky because employers provide health insurance plans and other benefits.

On the other hand, it is quite difficult if you plan on doing a full-time startup or are self-employed.

Being an independent consultant, I get my own health insurance. It costs me $2150/mo for a decent family plan (luckily we're all healthy!). Since my wife is pregnant, we end up paying another ~$1000/mo for additional costs after doctors visits. All this is before the 30% tax!

It's hard to imagine how people in other professions without employer-provided insurance manage to afford decent insurance or those who are disabled and don't qualify for full government benefits. This is probably way more difficult for single mothers when they're pregnant.

I hope that through our collective effort in knowledge sharing on dev.to we are able to help more people make a better life for themselves, their families and communities. This potential to make a difference is remarkable.

Does your employer pay for your health insurance in the US?

Did you know that Oracle owns the trademark to Javascript?

Nick Karnik — Thu, 04 Oct 2018 05:00:21 +0000

I have used Javascript for over 20 years, but I was unaware that Oracle owned the trademark to Javascript. If anything, I would have guessed that Mozilla owned it.

Oracle inherited the trademark after they bought Sun Microsystems (I didn't even know Sun had trademarked Javascript!).

I came across a Reddit post where Apple took down an App because the AppStore displayed the word JAVASCRIPT without authorization from Oracle.

I wonder if they will continue to enforce it in the future given that it is such a ubiquitous term. Many have suggested that we should refer to it as ES going forward and call it a day. I'm not sure how I feel about that.

Did you know about this? What are your thoughts?

How to Improve Your Debugging Skills

Nick Karnik ・ Oct 1 '18

#beginners #computerscience #programming #debugging

How to Improve Your Debugging Skills

Nick Karnik — Mon, 01 Oct 2018 09:22:30 +0000

All of us write code that breaks at some point. That is part of the development process. When you run into an error, you may feel that you don't know what to do. However, even the most seasoned developers introduce errors and bugs that break their code. We are humans after all.

The important thing is to learn from these mistakes and avoid repeating them by developing techniques to improve your programming and debugging skills. Errors are primarily logical or syntactical. Some of them manifest via exceptions or crashes while others may only be observed when using the software.

Here are some of the mistakes that developers make.

Failure to Log Messages

One of the most unhelpful scenarios you can run into is when your program crashes and there are no error messages to indicate what went wrong. The first step is to identify if the program is crashing on start or during runtime. You can accomplish this by printing a simple log message to the terminal at the beginning of your code.

If you don't see your log message, your program is most likely crashing while loading and it is possibly a dependency or build related issue.

If you see your message, you need to narrow down to the general vicinity of the crash. The best way is to strategically place some log messages throughout your program depending upon how much information you have about the execution path by the time it crashes. Then, all you have to do is see which messages are printed.

Failing to Read Error Messages

Exception messages on the front-end are usually displayed on the UI or developer console. Sometimes these messages are visible in the backend through the terminal or via log files. Regardless of where these errors occur, new developers are intimidated by them and fail to take the time to read them.

This is the number one reason why debugging takes longer for many developers. The first thing you should do is take the time to read the error message in front of you, let it sink in, and process it thoroughly.

Failing to Read System Log Files

Some programs generate log files or write to the system event log. There is often useful information in these logs. Even if it doesn't tell you exactly what is wrong, there might be a warning or error message or even a success message providing a hint about what happened before the error occurred.

Failing to Write Trace Logs

Tracing is following your program flow and data. Writing trace messages throughout your program helps simplify the debugging process. Trace Logs are an easy way to keep track of program execution throughout the runtime of your application.

Failing to Make Incremental Changes, Build Them, and Test Them

Many developers write big chunks of code before building and testing it. The time to find bugs increases proportional to the amount of code that was changed. You should strive to make incremental changes, build them, and test them as frequently as possible. This will ensure that you don't end up in a situation where a lot of code was written before you discover your program doesn't work.

Often, I will even refactor my code to simplify what I've written.

Failing to Write Test Automation

Unit-tests and end-to-end test automation allow you to catch potential errors as they happen. One of the reasons why existing code breaks is that developers refactor their code when they have low test coverage which means all changes are not tested automatically.

Failing to Use the Method of Elimination

If you're unable to identify the root cause of your issue, you need to use the method of elimination. You can comment out new blocks of code to see if the errors stop. Eliminating blocks of code will help you get closer to diagnosing the issue.

You can form a certain hypothesis and try to prove or disprove it. Many times a simple assumption can prevent you from finding bugs.

Copying and Pasting from StackOverflow

Often developers copy and paste code from stack overflow without understanding what it does. This has so many adverse effects. First, it is important that you pay attention to what goes into your application.

More often than I'd like, when I write a question on StackOverflow and think about how to effectively articulate it, I end up answering my own question!

Similarly, sometimes when I talk to other members of the team, I end up answering my own question. This happens because it forces you to think about your solution.

Failing to Solve their Problem Again

One of the most successful debugging techniques I have found is to try to walk through your solution over and over again and in some cases try to re-implement certain functionality from scratch. This forces you to find potential issues by recreating your implementation.

Failing to Backtrack

Normally, if you can isolate the symptoms to a specific area, you can start to walk up the call-stack to verify all variables and expected values. This can quickly lead you to uncover parts of your program where things are behaving unexpectedly.

Failing to Learn the Debugger

Finally, the single best investment you can make in yourself is to learn to use a debugger. All IDE's come with powerful debuggers. They follow the same basic concepts. They allow you to programmatically stop the execution of your application, either on start or in a specific part of the program flow.

There are also a ton of debugging tools that can aid in this process.

If this article was helpful, ❤️ it and follow me on Twitter.

How to Improve Your Development Experience

Nick Karnik ・ Sep 22 '18 ・ 5 min read

#beginners #career #development #productivity

Implementing the Queue Data Structure in Javascript

Nick Karnik — Thu, 27 Sep 2018 04:52:23 +0000

In this video, we are implementing the Queue Data Structure in Javascript. While a JavaScript Array can be used as a queue, this video is meant for educational purposes as we will go into more complex data structures in the future.

A queue is a simple linear data structure which is a container of objects that are inserted and removed according to the first in and first out principle. Elements can be enqueued from the back and dequeued only from the front.

Link to YouTube Video
Link to the CodeSandbox

If this video was helpful, ❤️ it and subscribe to my YouTube channel.

How to Improve Your Development Experience

Nick Karnik ・ Sep 22 '18

#beginners #career #development #productivity

Implementing the Stack Data Structure in Javascript

Nick Karnik — Mon, 24 Sep 2018 09:35:38 +0000

In this video, we are implementing the Stack Data Structure in Javascript. While JavaScript Arrays can be used as a stack, this video is meant for educational purposes as we will go into more complex data structures in the future.

A stack is a simple data structure which is a container of objects that are inserted and removed according to the last in and first out principle. Elements can be added and removed only from the top.

Link to YouTube Video
Link to the CodeSandbox

If this video was helpful, ❤️ it and subscribe to my YouTube channel.

How to Improve Your Development Experience

Nick Karnik ・ Sep 22 '18

#beginners #career #development #productivity

How can you swap two variables without using a third?

Nick Karnik — Mon, 24 Sep 2018 00:21:05 +0000

Moore's law is just an observation and not a real law like the Law of Gravity.

Over the years, developers have taken the increasing CPU speeds and Memory sizes for granted. Here's a warm-up interview question that I ask every candidate.

Let's assume the working memory for your function is 8-Bytes. You are given two 32-Bit Integers and you need to swap them. In other words, how can you swap two variables without using a third?

Please take your time to solve this and refrain from looking up solutions online or for answers below. This is your first step in becoming a Computer Scientist!

If you accepted this challenge, ❤️ it and [follow me on Twitter](https://twitter.com/intent/follow?screen_name=theoutlander).

How to Improve Your Debugging Skills

Nick Karnik ・ Oct 1 '18

#beginners #computerscience #programming #debugging

How to Improve Your Development Experience

Nick Karnik — Sat, 22 Sep 2018 07:31:14 +0000

To become a faster developer, you need to think beyond coding speed. You need to improve not only your core skills but also the physical environment, tooling and your approach to problem-solving.

If you are just starting out, don't get bogged down by the details. I have an elaborate setup because I work from home and I have been programming for over 25 years!

You will build expertise over time and fine-tune what works best for you. I am sharing what worked for me.

A comfortable environment

I cannot stress enough on how important a good sized desk is. You need enough space for your machine(s) and ample room to doodle. Make sure you can place a notepad, tablet, lamp, etc. and still have room to work comfortably.

Bush Business Furniture Series C 72W x 30D Office Desk in Mocha Cherry

What goes along with this is a super comfortable chair with armrests. I would highly recommend getting a headrest. If you’re going to spend 10–20 hours a day coding, you need a good chair. Even simple things matter such as how the armrest can adjust or where the neck support is placed, etc.

Steelcase Leap v2

Find the right hardware

It is important to work on a fast development machine so you aren’t waiting too long for your code to compile or application to render. The same goes for a good keyboard, mouse, and monitor. These things can add to the fatigue. I remember when working with Java 1.0, my research project took about six months to implement and I literally spent 3 months out of those waiting for the code to compile.

Ducky Shine 5

A multi-monitor setup is extremely important. I use a 43″ 4K monitor as my primary monitor and two 24″ HD monitors on either side. This works perfectly for most of the complex applications. The reason is that you need enough real-estate to get a good overview of things like the code editor, debugger for services, debugger for UI, browser, email, stackoverflow/forums, dashboards, SSH sessions, Spotify, dev.to :), etc. Using a laptop is fine, but I find that I am very efficient when I see everything at once and don't have to constantly switch between windows.

43" 4K UHD Monitor

Pick the right programming language

Regardless of what it is you’re working on, make sure to pick a language that has great tooling around it and community support. For example, Javascript, Python, and Ruby are common choices these days for most projects. I love working with C++ and C#, but there has to be a good reason to choose a compiled language.

Find the right tools

Back in the days, it was probably acceptable to use a text editor, but it is definitely not productive now. You need to find the right software tools. You need a very good Integrated Development Environment (IDE) since this is where you spend most of your time. You need to find something that allows you to stay within that environment. Some good choices are Visual Studio Code, Webstorm, Pycharm, etc.

Learn the core Computer Science theories & concepts

Data Structures
Algorithms
Design Patterns
Math
Problem Solving

You can find tutorials online for all of the above on YouTube, Udemy, Coursera, Udacity, etc. You should also go beyond just learning theory. Start coding these algorithms & data structures as it will help you improve your understanding of how things work and help you learn good coding practices.

Think of ideas to work on to solve your own problems and use those to hone your skills. This is a powerful combination and it helps keep you motivated.

High-level thinking / Architecture

You need to go beyond writing code to thinking in abstract terms. Think of breaking down the problem into big boxes with lines between them on a whiteboard (or notebook). You need to think of how to solve problems on paper first. In a corporate setting, you will also end up writing software design documents. Often, these are helpful at uncovering fundamental issues in the implementation ahead of time. Building good software is all about thinking through the process and breaking the problem down into modules that can be reused.

Clear Glass Dry-Erase Board

Soft skills

It is important to learn how to communicate and also interpret what is being communicated to you. If you can understand a problem/feature request from a customer or your team and translate it into proper requirements with an incremental plan on how to modularize the solution, you will save a lot of time during actual development.

Generally, I've spent most of my time on the whiteboard thinking about solving the problem and coordinating with other members of the team. I would say that coding is probably 60% of the work. However, these days I'm working as an Independent Consultant.

In Closing

At the end of the day, you will spend time on a keyboard and in front of a monitor crafting your code. You need to get familiar with hot-keys / keyboard shortcuts. These are a huge time-saver. This is something I try to observe when I interview candidates.

In addition, you need to automate anything and everything. You are an engineer first and need to apply your skills to make your job easier. If you find that you are repeating yourself, you need to find a way to automate it. Every piece of code that you write, needs to be re-usable. You also need to write test-automation so that you reduce the likelihood of breaking your code and wasting time finding and fixing problems later on.

Familiarize yourself with the plethora of libraries, frameworks and SaaS products that simplify your life. However, build expertise in at least one of them. At the same time, be sure to spend some time understanding how various technologies work and avoid using them blindly.

Finally, before you start coding, take enough time to understand the requirements and make high-level diagrams on paper. If you can solve the problem on paper first, it is just a matter of labor after that.

If this article was helpful, ❤️ it and follow me on Twitter.

I worked on MSN, Live, and Bing Search at Microsoft, Ask Me Anything!

Nick Karnik ・ Sep 12 '18 ・ 1 min read

#ama #career #search #beginners