DEV Community: Bijan John

Failure is just a stepping stone to success

Bijan John — Tue, 14 Feb 2023 12:09:24 +0000

At the end of last year, 2022, I took the AWS Certified DevOps Engineer - Professional Exam and failed it on my first attempt, obtaining a 699 out of 1000 where 750 would have been passing.

When I shared it with a few of my Developer friends I was reminded that "Failure is just a stepping stone to success". I feel fortunate to have this belief in my belief system after working in Engineering for several years, I also feel fortunate for the friend who reminded me of this (you know who you are ;).

I recently passed that exam at the beginning of February 2023, and I feel it is worth reflecting on a bit, so I am writing this post in hopes to remind my future self that "failure" is just part of the process; bonus points for if I inspire anyone else to attempt something difficult.

How do I learn Engineering and new Technologies?

I am a self-taught technologist who started working as a Level 1 support rep nearly 10 years ago in 2013, who now for the last several years has been in responsible for production systems.

I have taken a few course at my local Community College but ultimately the majority of my learning has taken place on the job or in self learning outside of work.

The most value tool/skill I have encountered for learning new technologies is to spend 1 hour a day (ideally at your ideal learning environment, for me that is in the morning) learning something new.

The progressive skill of learning requires time and patience and space to manifest and most importantly consistency (and resilience to keep up that consistency).

If you only spend a few hours a few times, you will not realize the gains of getting deep into a subject compared to someone who comes back each day for training.

A few more tips

It is ok to fail, try not to wait 6 months to a year before your next attempt. You will be not be starting over completely so take the next attempt a month or two later.
Try adding a few new materials to help you study. Using note cards, picking up a new practice test on Udemy and going over my notes helped me on my 2nd attempt.
Share your learning experience with others. Learning shouldn't have to be a solo event, if you can, pair up with a friend or build accountability with others so that you stay consistent and growing.

Below are a few Online Learning sites that have been helpful in my journey to obtain more certifications as well as skills as an engineer and developer.

A Cloud Guru

If you want to learn Cloud Technologies, I couldn't recommend this site enough. I used to be a member of Linux Academy before it was bought and mergd into A Cloud Guru (Parent Company Pluralsight) and this site has what you are looking for.

They have sandbox cloud accounts for all the major cloud technologies so that you can have real world hands-on experience to play with infrastructure.

They also have courses designed to help you pass most certifications with practice tests and quiz's and hands on labs.

This was what I used most to help me pass the AWS DevOps Professional Certification.

Real Python

If you are not a developer and are interested in learning a programming language, I couldn't recommend Python enough as a good language to start on.

Real Python is accessible to people on all levels and I frequently find their content extraordinary and very digestible.

They even have a great podcast that talks about different articles and new things in the Python world.

I am no longer doing daily Python development work, but I keep my membership to this account as I love the stuff they come out with and using them as a reference when I have a challenging Python problem is so helpful.

O'Reilly

My last company had a subscription to the O'Reilly Catalog of Books and Courses and what a treasure that was for my learning.

I used their content to help me learn Linux and passed my RHCSA (Red Hat Certified Systems Administrator).

I started teaching myself GO and a few other things from this site and I can't recommend it enough.

If you are an Engineer or Dev, chances are you have either purchased/borrowed or seen one of the O'Reilly books with a creature or animal on the front cover as they cover almost any technology you can think of.

Most of my favorite books are hosted on their site that you can read with a subscription; The Phoenix Project, Site Reliability Engineering, Software Engineering at Google to name a few.

Udemy

Udemy has a ton of great courses, in particular if you are studying for a multiple choice exam they likely have affordable practice tests for an exam you may be working on.

There are also hands-on courses that you can follow along with experts who have written the textbook.

A few of my favorites so far have been learning Kubernetes with KodeKloud with Mumsahd Mannambeth and Automating the boring stuff with Al Sweigart.

Whether studying for a certification or learning a new skill or building a new tool/project Udemy has lots to offer.

Laracasts

This is the newest site I have started using for learning, specifically to learn PHP, Laravel and Vue.

I am a PHP, JavaScript and TypeScript novice and those are programming languages used heavily at my new job, so I figured it was time to get more into these technologies.

I am still new to the platform but so far in the first course I have taken I am loving it.

To me, being a newcomer or a novice is exciting as I know that in learning something new I am going to make way more progress than going deeper into a subject I am more familiar with.

The greatest gains are to be had by someone who hasn't ever even started a new type of training.

This beginners mindset can be intimating, but maintaining a curiosity in learning and being ok with being wrong has been helpful in me overcoming the uncomfortable feeling of "not getting things right".

This was my first post of this sort, so let me know if this resonates with you at all and I may create some follow-ups on the subject and learning.

10 principles for Software Delivery

Bijan John — Fri, 04 Nov 2022 04:55:55 +0000

One thing that excites me most in my current work is figuring out how to build and maintain better systems to delivering software updates.

Below is a Quote from the DevOps Handbook from a Case Study Highlighting the importance of understanding the changes that we make.

In 2004, Gene Kim, Kevin Behr and George Spafford note that high-performing organizations recognize that

80% of all outages are caused by change
and 80% of MTTR is spent trying to determine what changed.

10 principles of software delivery

automation at scale
standardization across applications
continuous feedback loops
error budgets
test in a lower environment first
errors should be captured and improved
break up deployments to enable faster delivery
data driven decision making
decommission apps, environments and frameworks
continuous delivery to continuous deployment

automation at scale

Automation at scale means when we know a fix is available, we are primarily focused on delivering that fix to all customers and environments.
Applying a specific minor update to an individual customer in an adhoc way is also valuable, and there is a place for transformational self service however the ultimate focus for every organization is automation at scale.
Embracing automation means that we will seek to eliminate as much toil (manual work that is repeatable) to focus energy more closely on automation and building products that delivery value to customers.

standardization across applications

Standardization whether in the form of naming conventions, configuration, workflows, technologies or frameworks is important. Requiring standards like only allowing certain naming conventions in production services or even lower environments means you won't have automation break and there won't be special snowflakes to handle manually via toil.
Without consolidation of frameworks you end up supporting 3 different types of drivers, OS's, or frameworks.
Applying a very rigid standard across all elements of customers allows anomaly detection and the ability to understand immediately if a service belongs or not.
Most companies pay for services to be running because they don't know if they can turn it off or if they know they can turn it off they just don't know how to because of technical debt.
Standardization across applications allows for automation at scale.

continuous feedback loop

In the DevOps Handbook, The Second Way describes the principles of creating fast and continuous feedback loops from operations to development.
By doing this, we shorten and amplify feedback loops so that we can see problems as they occur and radiate this information to everyone in the value stream.
This allows us to quickly find and fix problems earlier in the software development life cycle, ideally long before they cause a catastrophic failure.

error budgets

Not all services are equally performant, some have a much older code base which can be larger and more complicated while others might be more green field and have fewer dependencies.
Services should be evaluated based on the number of issues that occur throughout the lifecycle of their release, customer impact (outages/degradation of service) is one of the most valuable measures to determining impact.
By better understanding the risk and challenges with each service delivered (and by breaking down monolithic apps into microservices) we can provide better gating as to which services will be released and which ones will require more work.
Error budgets are also a great way determine if engineering should have a clear runway for new features or if code quality requires more robust testing.

test in a lower environment first

This one almost seems too obvious to be in the list, however one might be surprised how many production services get deployed and run for customers without a lower environment first.
Always include lower environment testing and deployment prior to delivering (or even troubleshooting) in production first.

errors should be captured and improved

Every error is important. Often in software engineering a benign error will go overlooked and continuously be logged or returning a non 200 HTTP response.
Even if the error is "Known" or could be classified as non-impactful (red herring in troubleshooting), that error still takes up space in the minds of engineers, in the logs/metrics/traces and ultimately makes an application less observable.

break up deployments to enable faster delivery

By breaking up deployments into small batches to deliver updates more quickly and regularly we can reduce risk of big issues showing up across multitudes of customers, correcting issues as they are found in the wild.
Feature flags are a valuable way to deliver more modular updates of components in which we can deliver deliberate updates of increasing surface area to customers as we gain confidence in the updates before the entirety is delivered.

data driven decision making

Embracing telemetry to build observability into our updates help us understand the changes we are introducing into production.
We can test the code that is being cut by development pre and post update for quality and provide that data upstream.
We can also test our deployment pipeline to determine if any environmental issues or deployment issues happen pre and post update on the side of operations.

decommission apps, environments and frameworks

Letting applications, frameworks and environments run when they are not needed is incredibly expensive.
It is much easier to deploy new services than to know when and how we can turn off old services, or to understand if they are still needed.
By creating a central software delivery and deployment mechanism we can more assuredly understand what applications may be running but could be flagged for decommissioning.

continuous delivery to continuous deployment

Making use of all the tools and experiences to mitigate risk, monitor quality and improve software delivery speed we eventually get to the place of continuous deployment.
Continuous deployment is where each change committed to version control is integrated, tested and deployed into production.
Jez Humble defines continuous deployment as the following.

When all developers are working in small batches on trunk, or everyone is working off trunk in short-lived feature branches that get merged to trunk regularly, and when trunk is always kept in a releasable state, and when we can release on demand at the push of a button during normal business hours, we are doing continuous delivery. Developers get fast feedback when they introduce any regression errors, which include defects, performance issues, security issues, usability issues, etc. When these issues are found, they are fixed immediately so that trunk is always deployable.
In addition to the above, when we are deploying good builds into production on a regular basis through self-service (being deployed by Dev or by Ops)—which typically means that we are deploying to production at least once per day per developer, or perhaps even automatically deploying every change a developer commits—this is when we are engaging in continuous deployment.