DEV Community: morgana

A Tech Burnout Story

morgana — Wed, 30 Oct 2019 07:58:46 +0000

A couple months ago, I sat on the beach in Hawaii with nothing but disdain for all things tech. I stared at the watercolor sunset, feeling empty and drained thinking that a career change was in order. I was complete burnout in the tech industry.

The first tech job I landed was as a freshman in college 11 years ago and I absorbed everything. No blogs, books, documentation, tech courses, or tech talk escaped my notice. By the time I graduated, I was already bringing a lot to the table. I helped build out our Site Reliability Engineering team (SRE), and took on work I later learned was a few levels above a new grad. You might have even called me a “rockstar/ninja/wizard/10x/<insert some other bs term>” engineer.

I was an unstoppable freight train racking up accomplishments left and right.

Burned Out

Fast forward to 2018. Work was a burden. Waking up? Cumbersome. Want me to coordinate migrating a data center for 500 engineers? I’ll look at some postings on LinkedIn instead. Another incident? Another security issue? Yawn. Who cares. It’s just a job.

I became bitter and at times cantankerous. Work wasn’t interesting. Drowning in my depression, I started Googling for an interesting non-tech job. I needed something else because…

I was completely… and utterly… burnt out.

Catching My Breath

About the end of 2018, I reach out to a friend that had tried to recruit me a few times before then. He proceeded to tell me about the emphasis his employer put on life balance and taking care of ourselves. I took a shot and applied.

There wasn’t much to tell about the interview process except that they just wanted to hear my experience – no tricky code questions or anything.

They gave me an offer! The compensation was way more than enough to lure me over and even get me a little excited about the job. That burst of excitement didn’t last.

By the end of my first month I knew I was going to be fired. I had not accomplished much and I was desperate for a win. Just one simple win was all I needed to hold me over until I found a non-tech job. Then came my month 1 on 1 with my manager.

My bullet list of small steps forward was not anything to gloat about, but I figured I could sugar coat it just enough. The response shocked me.

“You’re doing great! Lots of real steady progress there! Yeah, let’s get you started on these projects now.” My jaw dropped and a small bit of tension relaxed in my mind.

It only got better from there. I was encouraged to attend and help out at conferences. They gave me all the flexibility in the world to take care of life things mid-day. Need to schedule a doctor’s appointment? Pick up kids from school every day? Np. Just let you lead know when you need to step away. We’ll make it work. Life happens and we need balance.

I had heard their philosophy and approach to work-life balance and even now it still boggles my mind, but I love it. Maybe I could do this tech thing still – if only I was still interested in it.

Vacation

Jumping ahead a few months, my tech lead reminded me that I hadn’t yet taken a proper vacation this year. I scheduled some time off and she said “No, take 2 weeks. Trust me – you’ll feel so refreshed”.

Since I had not taken anything beyond a staycation or family visit in at least 6 years, I decided to pamper myself. After looking for a nice vacation package I settled on Hawaii. I had heard great things from others who had visited and the idea of sitting on a beach with a book sounded divine.

I finally arrived. On my first day as I sat watching the sunset with a smoothie in hand, I wondered what it would be like to work at a resort. Maybe I would get free smoothies? That sounded better than writing up some code or reading another blog post about javascript. I sipped on my smoothie and enjoyed the warm breeze as the setting sun painted the sky… and I relaxed.

What IDGAF actually looks like

Burnout Mostly No More

The time in Hawaii was exactly what I needed. It was as if I had popped a healing potion and I was ready to code my brains out again. I was still in a fragile position though and I need to adopt a better balance in my life. I could still code late into the night if I wanted, but would need to make time for other hobbies. My brain clearly needed a break – and still does!

This year I have started reading more (non tech things), taken up kickboxing, painting, hanging out a farmer’s markets, and whatever else sounds remotely interesting.

One realization I had is that I look forward to each of these activities as much as I look forward to coding. Learning Rails and Preact so I can contribute to dev.to? When can I start? Kickboxing 3-4 times a week? Yeah let’s pummel that punching bag! Carving off 30 minutes of reading before I go to sleep? I love my local bookstore and it’s endless supply of fabulousness. Spending more time with family, teaching my dogs new tricks… YES PLEASE!

Some Science on Burnout

I love learning about how our brains work and I am happy to chat anyone’s ears off about what I learn. By no stretch am I any sort of expert so I’ll make sure to refer you some reading material to tie into my experiences.

Burnout causes all kinds of health problems. Everyone has unique experiences, but there are some very common results. Loneliness, depression, anxiety, and exhaustion to name a few. What’s upsetting is that this is on the rise. Not only is burnout damaging to your health, but it will take work to dig your way back out which is hard because you’ll already be exhausted.

I am both socially awkward and fairly introverted. At the same time I love people and making friends. However, when I try putting myself out there, I will swear on my life that something is wrong with my face. “Why are they looking at me? Oh because we’re talking. Doh.” At work it’s no different. I often focused on trying to impress the people around me by burying myself in my work and producing amazing results. Being social can be hard, but it’s even harder if you allow yourself to absorbed into the bottomless hole called “work”. If it starts to consume you, not only do you socially isolate yourself, you mentally, emotionally, and physically isolate yourself.

Here’s some reading material you should thumb through if you want to learn more:

Something short and sweet from Pyschology Today on Burnout – https://www.psychologytoday.com/us/basics/burnout

A bit from the World Health Organization – https://www.who.int/mental_health/evidence/burn-out/en/

Negative effects of Loneliness and Isolation – https://www.sciencenews.org/article/loneliness-isolation-brain-changes

Another detailed article on burnout from Psychology Today – https://www.psychologytoday.com/us/blog/high-octane-women/201311/the-tell-tale-signs-burnout-do-you-have-them. In a nutshell… it can get bad. Think about it. Is your life balanced?

More details from NCBI – https://www.ncbi.nlm.nih.gov/books/NBK279286/

Final Thoughts On Burnout

Here are 3 things that may help you recover from burnout:

Take a vacation. A real one. Seriously. What do you want? Ignore the taskmasters you work for and ask yourself, “What do you want?”. Me? I needed that stereotype beach with a little umbrella in my drink to let myself unwind mentally.
Look for balance. Are you working 20 hours a day? 16 hours a day? 12 hours a day? Take it easy. You’re actually becoming less effective by repeatedly throwing yourself at your work. Seriously, your brain cannot sustain processing that much information long-term. It needs time to recover. Find some hobbies. Some of the most effective and brilliant engineers I know have an active after-work life.
The corporate rat race is a soul destroyer. There are lots of good companies for you to work at. If you are able, run like hell from a job that is misaligned with your values, goals, or life balance.

Here are 3 things to watch for if you think you’re burning out:

You’re more irritable, cynical, or negative than what you used to be.
You’re putting in a lot of effort for things you have little control or autonomy over.
You start feeling dull, empty, or like you’re wasting effort and time – in my case this tied to depression.

It’s not easy and I realize many people are stuck in certain bad work situations. If you have the flexibility to make the needed changes though… do it.

Burnout is an ugly monster. If it comes for you or if it has found you, I’ll see you on the beach. We can bitch about “the man” together and sip on some smoothies.

Cool off and stay balanced! Reach out if you want to chat.

Puppies make everyone feel better. It’s science!

The post A Tech Burnout Story appeared first on Morgan Adams.

Learning Rails: Concepts To Know Before Starting

morgana — Fri, 18 Oct 2019 04:04:34 +0000

Me Learning Rails

Learning Ruby on Rails has been a fun adventure so far. Yesterday, I finished the Getting Started with Rails guide on rubyonrails.org which teaches how to build a simple blog app. Surprisingly, it does a thorough job of covering a number of features from working with the MVC to setting up routes and basic authentication.

I often hear that Ruby on Rails has a high learning curve – I want to dispute that. After finishing the guide, I feel confident I can start building my own apps using Rails and I think others can as well.

Key Concepts to Learn to Understand Rails

Admittedly, if you know a few things before diving into Rails, it will make a lot more sense. I plan to cover some of those things here in this post. They are:

Model View Controller (MVC) design pattern
Web frameworks
Convention over Configuration

If you are already familiar with these concepts, go ahead and jump into the Getting Started with Rails guide.

*Note : You don’t need a lot of Ruby knowledge to start, although it certainly helps. Just having some basic-intermediate level programming experience in general would be a good start. With the heavy emphasis on convention, you don’t need much code to get functioning CRUD operations and relations.

** Disclaimer : I’ve primarily been working in Operations, Site Reliability Engineering, and Security. So if my language isn’t precise on some of this, feel free drop me a note so I can correct it.

Model View Controller

First, lets look at MVC.

MVC is a common design pattern for the web. Although, you can see MVC in non-web applications it (and similar patterns) seems to be fairly ubiquitous around the web.

I won’t dive into a lot of MVC details since there exists an abundance of documentation on the subject, but I’ll cover some highlights.

Models are literally the object or idea you are trying to represent: an article, a search result, a goblin, a customer, etc.

Views are how you present information – specifically from the models. This often appears in the form of templates.

Controllers are the glue that tie models and views together. They take user requests, manipulate or retrieve models, and then render a view. In Rails, routes or URL paths map to controllers.

There is certainly plenty more on the subject and I encourage you to dig in more. Here are a few MVC articles to start:

Web Frameworks

If you think about what goes into building a web application, there are several common elements. Some of these are authentication, MVC, connecting to databases, input validation, and URL mapping – Wikipedia covers and links to more details [link]. Rails is such a framework and has a lot of these features readily available to help you focus on the business logic.

Because so much is implemented for you, you don’t always know the implementation details. That’s okay. Read the docs and play around with code examples. The behavior becomes apparent quickly.

Rails uses convention to conveniently tie the MVC part of the framework together. It might take a bit of getting used to it, but it’s achievable.

Convention Over Configuration

Rails focuses on Convention over Configuration. Although it might obscure some implementation details, it means less lengthy configs.

Previously, I worked in setups where there are literally hundreds of config files. Ultimately, you end up with config files with outdated options and a new source of tribal knowledge.

For example, the Getting Started guide you run a command to create your model. This also produces a db migration file. After running the migration, you will have a table whose name is the plural of the model. Additionally, it’ll do all the mapping between model and table attributes (Object Relational Mapping). In the end, convention saves you a lot of setup.

The Rails folks cover Convention over Configuration philosophy really well [link].

Getting Started With Rails

So now you know a little behind some of the key ideas behind Rails. Go follow their guide. It’s lengthy but it takes you from installation to a working app.

Screenshot of the blog app

When you finish, you will have worked with the MVC, routes, security, authentication, and a database. It’s just shallow enough to cover the important highlights and detailed enough to see how powerful it can be. Happy coding!

*NOTE : On the installation, you’ll need to install a few extra dependencies: nodejs, yarn, ruby-dev, build tools, and libz-dev.

The post Learning Rails: Concepts To Know Before Starting appeared first on Morgan Adams.

Getting a Tech Job with No Experience

morgana — Fri, 15 Feb 2019 06:17:42 +0000

I see so many folks out there trying to make their way into tech. They are often frustrated because they keep seeing “Entry-level with 2 years of experience” (yeah it's dumb and doesn't make sense), and it deters them from applying. Fortunately, there’s a great way to handle this and land that first tech job when you have no experience. This post shares what I experienced, and what I have seen others experience when trying to land that first job.

My First Interview

My eyes scanned the job board looking for something with programming. It was 2008 and I was brand new freshman at college. I had been getting into tech since high school where I started programming.

As I reached the last listing, I sighed. I qualified for literally none of the posted jobs. Even in college they still expect you to have X amount of experience for a tech job and I had no experience.

Luckily, I knew a friend of a friend who worked for the on campus IT department. I gave him my over-inflated resume and of course landed an interview! Connections, y’all!

Interviewer: Are you familiar with data structures?

Me: @_@ Huh?

They proceeded to explain what a data structure is.

Me: Oh yeah I know arrays! (If you aren’t familiar with data structures, arrays are barely even scratching the surface)

I didn’t get the job.

Instead, I ended up doing some fancy spreadsheets at the university library and some custodial work. It paid the bills at least.

Based on the coursework ahead of me, I was about 2 semesters away from landing any kind of programming job.

However, they kept my resume on file…

Getting My First Tech Job

One semester after my dismal interview, I was called and invited for an interview in the same office as my first interview.

Me: Look this sounds great, but I’m afraid you’re wasting your time. I already interviewed and they said no.

Them: This is for a different job and they want to interview you.

Me: This will be a waste of time.

Them: Do you want to interview or not?

Pro tip: Don’t be like me. If you want the job, take the interview. Luckily the person on the phone was patient as I ultimately accepted the invitation.

The day of the interview approached like a death march. The last interview was still vivid and my nerves ate at me.

I planned on talking about my ‘A’ in my intro to computer science class to show it had potential.

The subject never came up and I was again bumbling through another excruciating interview.

After I had told them for the millionth time “I don’t know”, they asked a question I could finally address.

Interviewer: What projects have you worked on?

Me: Oh, I made this pong game. However, it doesn’t have any bricks that disappear. As a result, it just bounces off the walls and you get a point every time you catch it before it falls off the bottom of the screen. I even made it two player! One person uses the arrow keys and the other uses a, s, d, and w. Additionally, I also made a chat program, so I know about sockets and threading and stuff.

Interviewer: Do you have them? (I had a thumb drive on hand and the most brick-like laptop you had ever seen)

We continued talking about my projects for 15 minutes. I figured this was a consolation question so the interview wouldn’t be a total joke. They then asked me to step into the hall for a few minutes.

After 5 unbearable minutes, they brought me back in, “We want to give you the job”. My soon to be manager handed me a monstrous book, “You start in two weeks. Learn Linux”.

The Lesson

Sometime after I started, I asked them why they hired me. They said I was green, but that I showed potential with my personal projects and they wanted to take a chance on me (for the non-English speakers out there, calling someone “green” means that they are new).

When you have no experience for your desired job in tech, make your own. If you don’t have any ideas for a project then make a chat app, make pong, make the best looking calculator with HTML/CSS/JS that you can, make a personal portfolio webpage with your mini projects, get a certification, or whatever else comes to mind. You might not have a few years of tech experience in a professional setting, but you _ can _ demonstrate that you have experience for the job with projects.

A Note on Recruiters

What I’ve learned over the years is that tech recruiters often don’t require you to literally have X amount of experience even though the job requirement says you do. If they ask for 1 year of experience and you have none, list your personal projects toward the top of your resume. That way they can see that you can do something and that may just satisfy their requirement. That’s far more important than a job like my fancy spreadsheets I made at the university library or the custodial job I had before that.

Showing what you can do as soon as possible will help them see where you could fit on a team.

Think of the “X years of experience” requirement more like a band. 1 year of experience might be 0-2 depending on what you can demonstrate to the interviewer. 5 years of experience might really be 2-5 years of experiences. Etc.

Ultimately, potential employers are looking for a good fit. The job requirements are often just their ideal which either is in short supply, or non-existent. Bonus: hiring managers often assume you will have a ramp up period in which you may have to learn some of the skills need for the job while on the job.

After working tech jobs for over 10 years now, I have never had a job for which I met every requirement – that includes years of experience.

Conclusion

Don’t get me wrong, there are jobs and recruiters that are sticklers about their requirements, but my experience is that is not the general case. They know that they have to fight for the budding talent out there. There’s a lot you can do to prepare for that next gig and there’s a lot you can do to craft that resume so that they readily see the fabulous-ness you can bring to the table.

If you don’t have the experience, make your own and get that first tech job!

The post Getting a Tech Job with No Experience appeared first on Morgan Adams.

Caesar Cipher Implementation in Python

morgana — Sun, 27 Jan 2019 01:23:34 +0000

Intro: About the Caesar Cipher

The Caesar Cipher is a simple cipher that has been around for a long time. Julius Caesar used it in some of his correspondence over 2000 years ago. It has applications in other ciphers, but offers no useful level of security due to how easy it is to decipher.

The cipher works by shifting each letter in a message the same amount for each letter. For example, if I set my rotation factor to three, the letter ‘a’ yields ‘d’.

To see this more clearly, the diagram below demonstrates how to handle shifts that reach the end of the alphabet. As the shift reaches the end of the alphabet, the ‘z’ wraps around and becomes ‘c’ using a shift of three.

Now, let’s take a more complete example. If we use a right shift of 20 and and apply it to each letter in the message “Hello World!”, we get the ciphertext “Byffi Qilfx!”

Conversely, if we want to decrypt this, we apply the cipher in reverse and shift left instead of right. From this, we see that the two variable parts of the cipher are 1.which way you shift, and 2. by how much.

Coding the Cipher

As an exercise, I wrote a simple python script to perform the rotations for me. First, I worked out the math for handling the shift (including wrapping) since this was the most complex part. Then, I iterated through each character and applied the computation. Finally, I added a simple CLI and then posted it to Github.

Below is my Caesar cipher implementation. Python doesn’t let you perform math operations on letters so you have to use the “ord” function to convert them to the Unicode code point first.

def apply_rotation(c, factor):
    """Applies a shift of factor to the letter denoted by c"""
    if c.isalpha():
        lower = ord('A') if c.isupper() else ord('a')
        c = chr(lower + ((ord(c) - lower + factor) % 26))
    return c

def caesar_cipher(s, k):
    """Iterates through each letter and constructs the cipher text"""
    new_message = ''
    factor = k % 26
    for c in s:
        new_message += apply_rotation(c, factor)
    return new_message

The Math

Let’s work through the apply_rotation method with a single letter, ‘a’ since this is a little difficult to read.

First, we assign the value of “lower” to ‘A’ or ‘a’ depending on the case to construct the shift. Looking at the inner parentheses we convert the character to a code point and subtract “lower”. The letter ‘a’ has a code point of 97 so if our letter denoted by the variable ‘c’ was ‘f’ (which has a code point of 102) we would get 5 (102 – 97 = 5). We can then add our shift factor (3 for our example) which gives us 8.

Before looking at the rest of the math, if you index the 26 letter alphabet 1-26, 5 is the letter ‘f’ which is what we want to transform. Adding the shift gives us 8 which maps to the letter ‘i’ which is our current result. Python doesn’t know 8 yields and ‘i’ though, but that’s okay because the remaining part of the equation fixes it up for us.

Performing a modulus of 26 just returns 8 for this example so we can ignore that for now. That leaves us with the last step of adding the Unicode code point value of “lower” to 8 i.e. 97 + 8 = 105. Now we can convert the Unicode code point back to a string using the python built-in method “chr” which gives us ‘i’.

Modulus

This is pretty simple math though, so why do we add lower and subtract it in the same equation? Don’t those cancel each other out? Yes, but since the alphabet is based on 26 characters we need to 0 out the Unicode code point values to our 1-26 index so that we can make use of the modulus to handle shifts that need to wrap.

The modulus helps us with our code wrapping. If we go through the math again, but instead apply a shift of 3 to the letter ‘z’ which has a code point of 122 we have to wrap the letters otherwise we get a code point of 125 which is the character ‘}’.

Ignoring the final, addition of “lower” the equation ends up being (122 – 97 + 3) % 26. This reduces down to 28 % 26. 28 isn’t in the alphabet, however when we apply the modulus we end up with 2. We finally can add the last “lower” to finish up with math which is 97+2 = 99. Applying the chr method we get the letter ‘c’.

Bonus: In the full code example, I use modulus 26 to handle shifts greater than 26. e.g. A shift of 27 is the equivalent of 1 (27 % 26 = 1).

Summary

The Caesar cipher is a simple cipher that shifts each letter by a set amount. We produce the deciphered message, by performing the shift in reverse.

The post Caesar Cipher Implementation in Python appeared first on Morgan Adams.

Deleting files that start with a hyphen in Bash

morgana — Mon, 21 Jan 2019 03:31:21 +0000

The Stage

I ran a script that takes a file path as an argument and it writes to that file. First, I ran it with the -h flag to see if I could get a help message. No error message printed to stdout. However, the script then did something unexpected…

After pressing enter, the script continued execution and prompted for additional input. I didn’t notice and hit “enter” a couple of times to get a clean prompt. This inadvertently allowed the script to finish. As a result, I ended up with a brand new file call “-h”. Oops.

Deleting a file is hard…

No big deal right?

$> ls
-h

We can just delete that with a simple “rm” command

$> rm -h
rm: invalid option -- 'h'
Try 'rm ./-h' to remove the file '-h'.
Try 'rm --help' for more information.

What…?

$> rm \-h
rm: invalid option -- 'h'
Try 'rm ./-h' to remove the file '-h'.
Try 'rm --help' for more information.
$>
$> rm "-h"
rm: invalid option -- 'h'
Try 'rm ./-h' to remove the file '-h'.
Try 'rm --help' for more information.
$>
$> rm '-h'
rm: invalid option -- 'h'
Try 'rm ./-h' to remove the file '-h'.
Try 'rm --help' for more information.
$>
$> rm '\-h'
rm: cannot remove '\-h': No such file or directory

At this point, I scratched my head in confusion. However, after some Googling I found a couple of simple solutions

$>rm ./-h
# or
$>rm -- -h

Either of these solutions works. The first works because we’re using the current directory as part of the path. This tells bash not to process the hyphen as an option.

Finally, the second option works because the double hyphen is a bash built-in. It tells the command that there are no more options to process and that anything else is a positional argument.

Wrap-up

In conclusion, I have a few lessons learned:

Actually look at your prompt before pressing enter
Shells have a lot of nuances. It’s worth taking the time to learn about them when you encounter them because you’ll likely run into them again.
Use “set -e” in your scripts. If there is an error, the script will exit rather than continue execution.

Learning Doesn't Have To Be Hard

morgana — Wed, 02 Jan 2019 01:20:15 +0000

My Journey

Walking into my Discrete Mathematics course in Computer Science, I felt like I had put on my big boy pants and was moving beyond simple coding projects. I was going to dive deep into Computer Science concepts and be a wizard programmer. I sat down and managed to get through some set theory, a few week later we started talking about graphs, Dijkstra's algorithm, proof by induction, and I looked like this guy:

I ultimately made a poor decision. I switched my major to Information Technology (IT). IT wasn't a bad major, it just wasn't what I REALLY wanted to do so it was a poor decision for me. The love learning hard things gave way to the pressures of life.

10 years later here I am, and so help me, I am determined to understand all the things I gave up! I have been building utilities and automating for years now. I understand systems, trade-offs, containers, Linux, architecture, design patterns, testing, security, project management, managing larger scale, design patterns, cross-team initiatives, and more. I appreciate every bit of that experience, but I still have major gaps in my programming ability.

Finally, I've circled back to what initially attracted me to tech and that was to dive deep into computer science, to understand the math behind the scenes, to know it well enough to teach others, to improve my ability, and build bigger and better things. That may sound boring to some of you, but I love it! Tonight I'm implementing Dijkstra's algorithm to make sure I understand it and I'm thrilled!

My point in all this is that you should focus on what's exciting to you. It's okay to be confused. There are resources to help you and I wanted to share some. Nothing I've done is a waste, my focus just drifted from what I was passionate about because I gave up for a period. No more! And I hope you will focus on what you're passionate about too!

There are more resources than ever out there. There is no reason a concept should be too hard to grasp because somewhere, someone has explained it in a way that may make sense to you. You just have to find it. I often joke that my job is knowing my way through a book or a search engine rather than engineering.

Some Useful Resources for Learning

Learning how our brains work is important

"Deep Work" - book on how to really learn concepts and ideas and how to make effective use of time.
"Learning how to Learn" is a course on Coursera. It was free when I took it. Alternatively, the book "A Mind for Numbers" is done by the same person and covers most of the same ideas.

Programming and Computer Science Resources

Book "A Common-Sense Guide to Data Structures and Algorithms". If you're newer to some of these concepts or have struggled to understand them, then this book is for you. I highly recommend.
100 Days of Code Initiative - Great idea, and I just started it myself! If you do it, let me know, I'll follow your progress.
Free Code Campus - Great if you can't afford a code campus and want to learn basics of web-development.
Hacker Rank - Useful for interview preparation, learning a new language, and deepening understanding of concepts. After solving a problem, you can switch over to the discussion tab to see how others have solved it. I re-implemented some of those solutions as a hands-on way to better learn some of the concepts that I may have missed or overlooked.
Meetup - A local community or group of folks to work with can open up a lot more work, practice, and networking opportunities. Who knows there might be a tech group near you, or maybe you can start one yourself! You don't have to be a pro to start one or join one. Just be willing to learn and make something happen.
And of course Dev - This is a great community!

There's a billion other resources out there. If you get lost or confused, ask for clarification or try another resource. Somewhere you'll find something that sticks.

What are your favorite resources? Which ones have been the most help to you?

Happy New Year and Happy Coding!

Pipelines: Not just a Pipe Dream

morgana — Sat, 29 Dec 2018 17:10:09 +0000

The Joke: Testing in Production

"Testing in production" has become a common joke in the development world - mostly because so many of us have been there and it kind of stings to think about it. You may have heard about these development pipelines, but after looking into them, thought it was too big an investment and the reality is that they're not cheap! Continuous delivery is not something you should try and spit out overnight.

Everyone wants to have confidence that when they deploy code to production and to know that their code is ready. Before having a pipeline of some sort, every release is like that scene from Jurassic Park, when Samuel L Jackson starts bringing power back on.

So how do we get to a point where we're confident our code is ready for production? Pipelines!

What is a pipeline?

Let's start with some definitions for those newer to this idea.

Pipeline - (from Gitlab https://docs.gitlab.com/ee/ci/pipelines.html)

A pipeline is a group of jobs that get executed in stages. All of the jobs in a stage are executed in parallel (if there are enough concurrent Runners), and if they all succeed, the pipeline moves on to the next stage. If one of the jobs fails, the next stage is not (usually) executed. You can access the pipelines page in your project’s Pipelines tab.
Environment - somewhere where your code runs for a some specific purpose
Staging - a set of computing infrastructure that runs your code for the purposes of integration testing, user experience testing, penetration testing, and other testing before deploying to your customers
Production - the set of computing infrastructure that runs the code your customers see and where customer data is stored

In other words, once we've put some code together, we first want to deploy it to some kind of staging environment that looks like production, test some stuff out, and then go to production. Your staging environment ideally looks exactly like production, but if you're cash strapped a local VM, Docker container, or their equivalent in the cloud will work just fine. The point is that you test your build to make sure it actually runs before you get to production.

Pipelines can unfortunately get more complex than that. Here are some components that may or may not be in your ultimate pipeline:

Merge Request
Commit
Changelog
Build Application
Code Analysis
Unit Tests
Integration/API Tests
Performance Tests
Multiple environments (Staging (often broken down into multiple environments), Production)
Smoke Tests
Regression Tests
Visual regression Tests
Release Candidate
Versioning
Promoted to Production
Dark launch
Percentage-based deployments (day 1 to 10% of customers)
Automated deploy
Metrics
Rollback

We could easily keep keep adding to that list, but it might already seem excessive if not impossible to organizations with limited resources or those unfamiliar with pipelines. Honestly a lot of these components will depend on what your organization needs and you may not need everything there.

The Gitlab link I mentioned earlier keeps it pretty simple https://docs.gitlab.com/ee/ci/pipelines.html, but it also has a feature set that supports building out your pipelines so if you don't use Gitlab you'll have to use other software. Here's a pretty tech agnostic diagram that they use on that page that shows what your pipeline could look like at a high level

So Where Do You Start?

Where you start may depend on resources available. If you are cash strapped or running a project solo, you can still have a pipeline! If you have the resources to start building out a pipeline, but are only just now getting started, no problem because I would recommend starting in the same place.

Create a script that can build your software
Create a script that can deploy your software once it's built. This can also be reused to deploy to a staging environment if you have one available.
Create a script that can roll back to your previous release

You are already doing these 3 things anyway. You might as well automate those steps with scripts. You can always replace these with something more sophisticated later.

Next Steps

Once you have those 3 pieces you can start introducing other components with minimal investment.

Ensure code reviews are part of your process if you're not running a solo project.
Start adding unit tests every time you touch the code. When you run your build, add a few lines to execute your unit tests. Toss in a linter while you're at it.
Add a staging environment of some sort. With a bit of scripting you can do something phoenixable (quickly create/destroy) in AWS or even in a local VM (run a local container, or maybe check out vagrant) if you want. You have options.
Use something like git tags/docker labels to version your code.
Maintain a changelog

There are free tools or modules you can download to help you with most of these steps. Pretty much every language has testing libraries and ways to measure code coverage. You can also easily find linters.

Why bother?

I have been on more calls at 2AM than I care to think about - sometimes consecutive nights! It's a dark place to be in (no pun intended) when you are debugging production from 2-6AM.

An investment in a good pipeline will save you a lot of pain and heartache and ultimately give you confidence in you and your organization's ability to release quality software. Even better, your customers will be more satisfied.

Make Progress

There's a lot you can do improve your development pipelines. You don't have to do it all. Start slow, start easy. You don't even need to follow my suggestions, start with what's right for you/your team. Identify quick wins. There are a lot of tools out there to help you in this process.

Eventually you can get to a point where most things are automated. Some of my favorite parts of an automated pipeline is after a deploy to production, you have monitors that watch your metrics, determine that your new release is sending page times through the roof, and triggers an automatic rollback or at least a notification that you may need to rollback. Then I can wake up at 2AM push the button to roll back and go back to sleep!

Here are the some key principles

Leave your code/pipeline a little better every time you touch it, whether it's an additional unit test or automating some piece.
Look for the quick wins. Some of them may save you heaps of time.
If you have a long release cycle, a good pipeline can help you ensure quality leading up to a release.
Focus on quality. That new feature doesn't help anyone if it errors out all the time.
Don't rush to production if you can help it.
Don't test in production!
Sleep better

I love a good quality pipeline. What have you seen work well? What would you add? What would you like to see me talk more about? I'm happy to go into more details if folks are interested.

Programming Challenges: More Than Just Brain Teasers

morgana — Mon, 24 Dec 2018 10:07:59 +0000

Intro: When All You Have Is A Hammer

"When all you have is a hammer, everything looks like a nail". This is known as the "Law of the Instrument" or "Maslow's Hammer" (plus some other monikers). The meaning behind this is that sometimes we get familiar or comfortable with a tool and bias towards using that tool to solve problems. This post is a tale of a recent experience I had where I let go one of my hammers and added something new to my mental tool belt.

I deviated from programming early on in my studies and moved to a more operational role. One thing that was readily apparent is that the tools and systems I learned about handled problems to varying efficacy. MySQL is not always the best database. Nginx isn't the best load balancer even if you can get it to load balance. Just because I can write a 1000 line bash script doesn't mean I should.

Ultimately, I've had to continue learning about new ways to solve problems. I subscribed to various blogs, watched conference talks as they were posted online, followed engineering leaders on Twitter, and even gave up Perl (this was about 8 years ago :) ).

I've recently started focusing on my programming skills again, but before I talk about that, first a flash back to when I first started programming as a teenager.

A Pattern

Given an m x n 2D array which represents a maze, return a list of indices representing the solution to navigate the maze.

As a 17-year old programming newbie in Java, I was stumped. Every time I ran some tests, "ArrayIndexOutOfBoundsException" or "Error: Returned solution has 0 entries". Smashing my face on the keyboard and a few choice swear words later... I gave up.

It was a rough experience, but what I remember most was when another programmer showed me how he would mark paths he had traversed with a 2D boolean array of the same size to track where he had been. I thought it was the most brilliant solution ever. Clearly I hadn't been out much, but it was like a light turned on in my head. I distinctly remember him saying "Sometimes it's just easier to use a separate structure for tracking things". Note that he said "Sometimes" and not "Always" because I didn't at that point.

I soon saw other programming challenges where maintaining another structure to track "visited" items proved very handy. The first time I reused this approach was when I wrote a program to find words on a Boggle board. Handy! But it didn't always work and even made the problem harder.

Present day

Fast-forward to present day... I'm happy to say, I am now working on my programming skills again! I love to build!

Hackrank is where I currently spend a lot of time working through various programming challenges and reading the associated discussions about how others have solved the problems I was working on (this is actually one of my favorite things about these challenges).

Cycle Detection

SPOILER ALERT - I talk through some details about solving a Hackerrank challenge here

Recently, I came across a challenge that prompted this post: "Cycle Detection". In this challenge you are supposed to detect a loop in a singly-linked list. I knew this pattern! I would just keep a separate structure with the nodes I had visited and detect the loop if I crossed one of those nodes.

Fortunately, all the edge cases on all these problems I had working on made the cogs in my brain start turning. Something about the solution didn't seem right. It's not wrong, but what if I had a linked list that had a million nodes? What if it had more? Was there another way to solve this problem?

After submitting my solution, I flipped over to the "Discussion" section where my eyes were opened and I drooled over someone else's short and elegant solution.

They simply had another pointer that traversed the list twice as fast. If the first pointer and the second pointer where ever identical then there was loop in the linked list. Clever and SO much simpler than my solution!

Where else might I see collision type problems? Maybe I had just discovered another pattern... I casually added that to my mental tool belt. It was interesting as I thought about that solution and how both of these techniques could be used in networks (among others).

Your Mental Tool Belt

Learning the fundamentals is a lot of fun. What is even better is when you start to draw connections between various fundamentals and you see a bigger picture. Learning different ways to approach problems gives you more to work with and enables you to move beyond your hammer - or rather, it helps you identify when the hammer is the right tool for the job.

What makes you and I better at what we do is learning how to solve problems and learning new ways to do it! Even for the simple things. Even as we become more advanced and develop expertise, it is important to set aside our bias (hammer) and see how else we can do things.

Do you have more than just a hammer? Do you see too many nails? Keep honing your craft, try something new, explore a new subject, read another book, read another dev.to article - whatever you do... keep learning!

That's Brilliant!

morgana — Fri, 23 Nov 2018 06:44:21 +0000

We don't share enough

I had just walked out of meeting where we were discussing a roadmap for some of our internal systems. I had an idea that could have solved a particularly hard problem, but just sat on it and kept my mouth shut until after the meeting.

I pulled my manager aside and shared the idea with him. “That’s brilliant! Why didn’t you say so earlier?”. I just stared back - I was expecting to get burned for a bad idea. He proceeded to chase down everyone who was in that meeting to talk to them about it and telling them that I had thought of it. I was at a loss, but that didn't stop me from strutting around the rest of the day.

Why you should speak up

There may be some of you who have had similar experiences. I see it with other engineers all the time - especially now that I am running a team of my own.

I don’t know what makes us not share or speak up more. Maybe it’s impostor syndrome, maybe some of us feel there is a hierarchy and the junior engineer shouldn’t speak up, or maybe we just assume someone else has already considered it. It really doesn't matter - the end result is that we don't share enough.

I’m here to tell you that for whatever your reason you and I don’t speak up, it’s wrong. For those of you in a toxic work environment where offering solutions isn’t valued, find a new job when you can. That kind of environment will hold you back and you don't need that kind of negativity in your life anyway.

You are an engineer and your employer hired you because they thought you had something to contribute. It’s up to you to deliver. That means not only writing code and implementing someone else’s solutions, but to come up with your own solutions, speak up, and share them!

4 reasons why you should share your ideas:

Your view of the world is different. Ignore that saying “you’re unique just like everyone else” which implies you’re no different from everyone else. Your experiences and perspective have a unique spin that make you see things different from everyone else. You have something to contribute and it’s honestly worse to have the solution and your manager get exasperated when you sit on it (story of my life - trust me).
You might learn something. Ideas get shot down all the time and that is perfectly okay. I have learned so much from some of the senior engineers I have talked with as they show me better ways of approaching problems. They often have something to teach if you’re willing to listen. Do this enough and you’ll find that you become the person with something to teach.
You’re idea is a piece of the puzzle. One of the main reasons you brainstorm in groups is because even the most knowledgeable people don’t know everything. How many of you have been exasperated at a senior engineer or manager because they didn’t “get it”? As an engineer you need to learn how to help them understand (again, find a new job or role if you are in a culture in which this is hard to do). You don’t have to be the hero with all the answers. You would be surprised how much folks appreciate it when your idea helps fill in the gaps.
Your career growth will accelerate. When you share ideas, others learn how you think and will start to understand you and your expertise. They’ll be more willing to work with you and brainstorm with you. Soon you’ll be mentoring others and develop a network of engineers you can reach out to to help get things done. You will even find people coming up to you saying “I hear you’re the expert on [something]”.

Find your way forward

I know so many of us don’t enjoy interacting with people as much as we do the tech. You have so much to gain though if you make the effort whether you want to get into management, build stuff, or become that senior engineer that is a mentor to many. Take it from this shy, introvert drowning in impostor syndrome and is happiest behind a monitor than in a group of people. Sharing ideas has a multiplier effect if you want to progress your career and get things done.

If you don't know where to start, try a post here! Share something you've been learning about recently, show off a project you're working on, or throw out an idea worth discussing with others. It doesn't have to be earth-shattering. Even simple ideas or learnings need to be shared. There's a good chance someone else needed what you've been learning about.

Admittedly, this my debut post on dev.to. I have been a silent reader for some time and am finally eating my own dog food, coming out of my shell, and trying to give back to this community. Give it a try yourself and write your own post. You might be surprised how many people resonate with your ideas. You might even find folks who comment “That’s brilliant! Why hasn’t someone said that before?”