Forem: Donna Amos

Things I've Learned My First 90 Days as a Junior Developer

Donna Amos — Sat, 16 May 2020 19:36:33 +0000

Getting my first junior developer job was a long, hard road. A road that I could only see ending at the start of my job. I was so overwhelmed by the process of learning to be a developer that I didn't have the capacity to think about what I should do after I got the job. I tried to think about it but it's hard to think about something you've never really experienced.

My first ninety days were somewhat rocky as they didn't have a set training program for juniors and a month after I got hired, the country went into lock down during the coronavirus pandemic, causing me all kinds of added anxiety on top of learning all the things at my new job. I made lots of mistakes and took longer to get results than I would've liked.

Here's a list of what to do, what not to do and how to avoid the pitfalls that come up in the ever changing world of development at your first junior developer role. This list is by no means exhaustive and I'm sure there are others who've had different experiences for better or worse than I have. This is only from my experience and should be taken as such and nothing more or less.

Communicate, communicate, communicate

The importance of communication cannot be overemphasized. It's the foundation of all that programming is and without it, nothing can be done. If you don't know something or don't understand something don't smile and nod. Ask how to do it or what that word means. If you don't communicate what you're doing, what you have done and what you do or don't know, you're figuratively blindfolding your manager as to what you should be doing and his/her expectations for you. Your both adults and you don't have to be babysat by them but you do need to let them know exactly what you are doing with your time to make the most of it.

Knowledge is important but a good attitude is more important

Most programming jobs put emphasis on how much you know and while that is essential to your job as a developer, it's not as important as staying on good terms with your coworkers and your managers. You can have all the talent and abilities in the world but at the end of the day, it's your attitude and a kind spirit that keeps you at your job. If people enjoy working with you, they'll be much more likely to allow for mistakes and help you through gaps in your knowledge till you can catch up. Patience and understanding is worth twice as much as knowledge, which is saying a lot considering most companies hire for your knowledge. Both are valuable but a kind spirit is the most valuable.
Remember, it's not what you say, it's how you say it.

Problems: Is it a company specific or a general programming problem?

Learning programming is overwhelming. Even if you've been at it for several years, it's a lot to take in and there's so much you have to know. One of the things that really helped me was to distinguish between a company specific problem (e.g. do I have the right permissions? How does this system work?) versus a programming problem (e.g. Is this a bug I can find on Stackoverflow?)
Once you can pick up on these patterns, it's much easier to know where or who to go to for help. If it's a company problem, ask right away. If not, Google it first before asking for help. Which brings us to the next topic.

How to ask for help

As a junior, it's normal to ask for help. But asking for help is a skill in and of itself. First, determine what kind of a problem you're working on as we covered in the last paragraph.

Next, Google the problem. If you've spent 30 minutes Googling and trying different solutions and nothing has helped, then ask. Be specific when you did. Communicate the problem, what you've tried and one specific question all the while taking into account they might be busy.

I usually will send the question on Slack and let them know they can get to it when they can. Don't rush or be rude with another developer when asking for help. They have a full amount of work themselves and you are taking up their time. Don't apologize either though. It's part of their job to help you through a problem and help you learn what you don't know. Thank them instead. Thank them every time no matter how small the problem or quickly you figure things out. They're giving up their time and that's not always easy.

Also, write down the steps it took to get through the problem for reference later. There are no dumb questions the first time but if you keep asking the same question over and over, you're not asking for help, you're asking them to do your job for you.

You will have good days and bad days

We all have our days where we're feeling good and getting stuff done. Then there are those days where we feel terrible and everything seems to blow up in our face. That's normal. What you have to fight is discouragement. As a junior, you will have a lot of bad days when nothing seems to go right, you don't feel like you will ever know enough and you will never catch up. But don't let that discourage you. Think of these days as times for you to fail and learn from those mistakes. I've made plenty of them but I haven't given up. I can't and don't want to. If I lost this job, I would look for another one. It's okay to get discouraged and have bad days but don't let that stop you. Another thing, when you do have a bad day and feel like crying, go ahead and cry. It's unhealthy to suppress those emotions. You can wait till you get home or do it in the privacy of the restroom but go ahead and let it out so you can move on again. It's not weak, it's called being human.

What you should focus on learning

Learn the flow of the system from cloning and downloading the repository to deploy. And don't forget to test your work after you've made updates or changes to the code. You can ask for a lot of help to understand how the system works and what to do. Take lots of notes and keep good records. Also, practice as much as you can going through the process. Experience is after all the best teacher.

Learn how to use the tools (have someone help you walk through them). Developer tools have many features and if misused can result in some devastating events that could be avoided. I once ran a SQL update on a database, not realizing it would make changes and it took my boss eight hours to fix it. It was bad and I was horrified but I learned a valuable and painful lesson: slow down and learn how to use things before you royally screw things up. I've slowed down and been more careful ever since.

Invest in yourself: buy books, courses, whatever you need to get to do better at your job. Do them in your off time or in your down time while waiting for feedback or further instructions. This profession is built on learning and growing every day. You can't know everything but you can learn a little more every single day. Take a massive problem or process and break it down into smaller bite sized pieces.

Get very familiar with basic computer literacy processes and learn things other than coding languages. There's a lot more to programming than just coding languages. Principles and processes are more important to learn than languages as they can be changed but most processes and principles stay the same. Computers are complicated and there are a lot of people that have trouble using them and a lot less who know how they work on a deeper level. You must be vigilant and dedicated but don't try to remember it all. Good notes and careful records are ten times better than the best memory. Write it all down and practice, practice, practice.

Take care of your health or your performance will suffer

Your health is incredibly important to your work. It seems most devs suffer from insomnia and migraines. I believe this is due to stress. Being a developer is stressful since you can work for ten hours straight and still not see the results of what you've done. And then there's the overwhelming amount of knowledge you need to learn, coupled with daily tasks, communication, deadlines, meetings and no end in sight. It can get to be a black hole you feel you can't get out of and if you don't keep up your health, you could end up with anxiety and depression and other problems.

The first thing I would recommend is a good night's sleep. There's no amount of coffee you can drink that will replace it. Next, is making sure you get outside at least 15 minutes a day to get some sun and a short walk. Even a walk every day is better than a long exercise routine once a week. It makes a difference.

And don't forget to eat healthy and drink plenty of water. It's easy to grab pizza on the way home but eventually it will catch up to you if you do often enough. That doesn't mean that you can never do it. Just be smart about it and try to keep it to a special occasion. Remember, eating right is more about balance than restriction.

Do your best

This is possibly the most important. It's easy to coast in the short term but it's also easy to for others to see through it. Your manager will pick up pretty quickly if your not getting things done. Doing your best, asking questions, taking notes, learning new things everyday is what really matters. Little by little you will start to see big results.

Don't compare yourself to other juniors or think that you aren't a real developer because you didn't know something that was "common knowledge". You're job is to learn and do your best while your starting out. At the end of the day, that's all you can do.

I hope you've learned some things from this short post and if you have anything else to add be sure to post in the comments below. Thanks for reading and good luck on your journey.

Tech Acronyms/Abbreviations Cheat Sheet

Donna Amos — Tue, 20 Aug 2019 00:14:47 +0000

I have a fairly poor memory when it comes to memorizing shortcuts, passwords and all things acronym.

Tech has SO many of these that I finally decided it would just be best to list them all here and I will reference them when my memory fails me.

I'll be adding to this list from time to time so feel free to comment your own abbreviated tech-related jargon and I'll add it to the list below. Each term is linked to its Wikipedia page for a quick reference.

AJAX - Asynchronous JavaScript And XML
API - Application Programming Interface
AR - ActiveRecord
CLI - Command Line Interface
CRUD - Create Read Update Delete
CSS - Cascading Style Sheets
DB - Database
DoD - Definition of Done
DOM - Document Object Model
DRY - Don't Repeat Yourself
ERB - Embedded Ruby
JS - JavaScript
JSON - JavaScript Object Notation
HTML - Hyper Text Markup Language
HTTP - HyperText Transfer Protocol
IDE - Integrated Development Environment
IIFE - Immediately Invoked Function Expression
MVC - Model-View-Controller
NPM - Node Package Manager
OOP - Object Oriented Programming
ORM - Object-Relational Mapping
REGEX - REGular EXpression
REST - REpresentational State Transfer
SQL - Structured Query Language
XML - Extensible Markup Language

OO Ruby Concepts Part 3, Object Relationships

Donna Amos — Thu, 25 Apr 2019 02:23:15 +0000

Last post we gave an object its attributes so it can become its own entity. But the object we made, Garfield, can't interact with any other objects. That's where object relationships comes in. If objects are modeling real world entities, they need to have a method to know who they belong to. This method is called "belongs to". Let's start with building the "Garfield" object.


class Cat #object 
     attr_accessor :name # gives the object a name

   def initialize(name) # Initialize method means the name attribute is called when #new is called 
     @name = name 
   end 
end 

garfield = Cat.new("Garfield")

Now that we have made a cat object, Garfield, we need to give him an owner. Who else will feed him lasagna?


class Owner #object 
     attr_accessor :name, :job # attributes about the object 

  def initialize(name, job) # Initialize method means the name and job attributes
    @name = name            # are called when #new is called.  
    @job = job 
  end 
end 

 jon = Owner.new("Jon", "cartoonist") # new method names the Owner, Jon, 
                                      # and gives him a job, cartoonist  

 garfield.owner = jon # Congrats! Now Garfield belongs to Jon.

Now Garfield knows that he belongs to Jon. However, what if Jon wanted another pet? In the real world, he can own as many pets as he wants. He's decided to get a dog. How do we give Jon another pet?

With a method is called the "has many" relationship. It allows an object to have many objects and relate to one another. In this example, it allows the Owner, Jon, to have two pets. And any more if he wants them.


Class Owner 
   attr_accessor :name, :job 

 def initialize(name, job) 
   @name = name 
   @job = job 
   @pets = [] # this empty array is where all Jon's pets will go 
 end 

 def add_pet(pet) # this method allows Jon to add as many pets as he wants
   @pets << pet # the shovels(<<) push the pet class we've created into the array
 end 

 def pets # this method simply returns the @pets array when it is called
   @pets 
 end 
end 

 jon.pets # => ["Garfield", "Odie"] this is the pets array when it is called

Now we need to make an Object called Pet that we can use to give Jon more pets when this method is called.


class Pet 
       attr_accessor :name, :species  

   def initialize(name, species)
    @name = name 
    @species = species 
   end 
end 

  odie = Pet.new("Odie", "dog") # "Odie" is the name, "dog" is the species
  garfield = Pet.new("Garfield", "cat") # Congrats! Jon can now adopt his two pets.

One more method to bring all this together. The self keyword refers to the owner we're calling on.


   pet.owner = self

Add this to the add_pet method so we can call the self keyword to let the pet know who his owner is.


Class Owner 
   attr_accessor :name, :job 

 def initialize(name, job) 
   @name = name 
   @job = job 
   @pets = [] 
 end 

 def add_pet(pet) 
   @pets << pet 
   pet.owner = self # self keyword 
 end 

 def pets 
   @pets 
 end 
end 


 jon.add_pet(garfield) # calling the add_pet method 

 garfield.owner.name # => "Jon", Garfield knows Jon is his owner 

 jon.add_pet(odie) 

 odie.owner.name # => "Jon", Odie knows Jon is his owner 

 # Now Jon has two pets and they know they belong to him!

OO Ruby Concepts Part 2, Object Attributes

Donna Amos — Thu, 11 Apr 2019 22:17:47 +0000

Last post I discussed objects and their behavior. This post will cover the attributes of an object and how to manipulate them to cause a certain behavior.
Every object has attributes. To make this clear, I looked up the definition of "Attribute" on Google and here's what it said:

at·trib·ute

verb
1.
regard something as being caused by (someone or something).
"he attributed the firm's success to the efforts of the managing director"

noun
1.
a quality or feature regarded as a characteristic or inherent part of someone or something.
"flexibility and mobility are the key attributes of our army"

Let's stick with our Cat class from the previous post and give it two attributes, name and breed, using the 'setter' and 'getter' instance variable methods.

class Cat # Object 
  def name=(garfield) #setter 
  @name = garfield 
  end 
  def name #getter 
      @name 
  end 
  def breed=(tabby) #setter 
     @breed = tabby 
  end 
  def breed #getter 
     @breed 
  end 
 end 

garfield = Cat.new("Garfield") 
garfield.name # "Garfield"

This block of code contains both a "setter" and "getter" method which writes or sets the attribute and then reads or gets the attribute for the object to use. This code is long and becomes repetitive very quickly and unless you need to customize it, there's a better way to set and get attributes.
We use macro programming to accomplish this. Macros are a tool that allow programmers to reuse code. Attribute readers and writers are macros that implement this same code above with only two lines of code.

class Cat 
   attr_writer :name, :breed  #setter
   attr_reader :name, :breed  #getter 
end

As you can see, much more efficient. William Strunk, in his classic book "The Elements of Style" said, "Omit needless words". Macros in programming omit needless code and allow the attributes to be added much more seamlessly. The attribute writer and reader can be further condensed with the attribute accessor like this:

class Cat 
    attr_accessor :name, :breed # setter and getter all in one line
end

Now let's make a new cat, with a name and breed and make it "Meow!" using the attribute accessor.

class Cat 
    attr_accessor :name, :breed 
    def meow 
    puts "Meow!" 
    end 
end 

garfield = Cat.new 
Cat.name = "Garfield" 
garfield.name # Garfield 
garfield.breed = "Tabby" 
garfield.breed # Tabby 
garfield.meow # Meow!

OO Ruby Concepts Part 1, Object Behavior

Donna Amos — Wed, 10 Apr 2019 00:50:16 +0000

Ruby's object oriented programming is hard for me to get my head around. To help me understand OO Ruby better I've decided to write a mini-series solely focused on the concepts behind the programming.

I've found when learning anything, it's best to look up the definitions of the words themselves. What is Ruby programming and what's it used for?
Let's ask Google:

Ruby is a dynamic, interpreted, reflective, object-oriented, general-purpose programming language. It was designed and developed in the mid-1990s by Yukihiro "Matz" Matsumoto in Japan. According to the creator, Ruby was influenced by Perl, Smalltalk, Eiffel, Ada, and Lisp.

Ruby (programming language) - Wikipedia

What can Ruby be used for?

It is used in a wide range of fields, but is best known as a language for Web Applications, because of the Ruby on Rails framework. The general purpose nature of Ruby makes it suitable for a wide array of programming tasks, just like Perl, Python and other general purpose languages.

What is the Ruby language and in which field is it used? - Quora

Great! Now that we know what Ruby is and what it is used for, we're ready to ask the next question. What is Object Oriented Programming? Google, if you please:

Object-oriented programming (OOP) refers to a type of computer programming (software design) in which programmers define not only the data type of a data structure, but also the types of operations (functions) that can be applied to the data structure.

What is Object-Oriented Programming? Webopedia Definition

You're probably thinking that I'm just looking up stuff on Google. And you'd be absolutely correct. Knowing how to use Google is one of the best skills a programmer can develop. It's a good idea to get really good at it by using it often.

Now that we know what Ruby is, what it is used for and what object oriented programming, is we're ready to actually start coding. What I like to do is to get out a code block from Github, Codepen, or anywhere code is made and look at the code itself to break it down.Kind of like reverse engineering, only with code, you can use comments to explain as you go.

I'm not going to take the time to explain every concept of OO Ruby. Just the Object's behavior and how it can be used in programming. Let's get right into it with a block of code with an object Cat and make the Cat do stuff. Let's even give it a name. Then I'll start breaking down the concepts of the object's behavior.

class Cat # Cat is the object 
   def name=(cat_name) # the 'name' variable is created here 
       @this_cats_name = cat_name # Setter: sets up the variable for the object 
   end 
   def name # this is now an instance variable. It can be called to create new Cats. 
       @this_cats_name # Getter: gets the variable for the object 
   end 
   def meow # this is a local variable and can only be used make the Cat object meow. 
       puts "Meow!" # no new cats can meow here 
   end 
   def come # no new cats can come. Don't worry they won't come anyway. 
       puts "I'll come when I'm ready!" 
   end 
end 

garfield = Cat.new
Cat.name = "Garfield" 

puts garfield.name # "Garfield" Congrats! You've made a new cat! 

garfield.meow # Garfield can't meow. Why? meow isn't an instance variable like 'name'.
cat.meow # "Meow!" Cat can. Why? meow is a local variable. Only Cat can use it.

This is a lot of code to begin with so let's build each method one at a time.
First is the class method which acts as the blue print for building the object itself.

class Cat 
# method body where stuff is built for the Cat 
end

Now that we have the object Cat in our class method, let's write a local variable using an instance method and make the Cat meow.

class Cat 
   def meow 
   puts "Meow!" 
   end 
end 

cat.meow # "Meow!"

We made the Cat meow by creating an instance method within the class method. Instance methods make the object do stuff. The Cat can't meow unless the method is called using dot notation. Hence:

cat.meow # puts "Meow!"

This is great! Only now we need to name the cat. Since local variables can only work on the object Cat, we need to find a way to create new cats using all the same instance methods. Otherwise, we'd have to repeat all the instance methods for every new cat. Since we're lazy programmers it's better to just reuse all the methods in Cat for every new cat we want to create. How is this done? Enter the instance variable:

class Cat 
def name=(cat_name) # the 'name' variable is created here 
       @this_cats_name = cat_name # Setter: sets up the variable for the object 
   end 
   def name # this is now an instance variable. It can be called to create new Cats. 
       @this_cats_name # Getter: gets the variable for the object 
   end 
end 


garfield = Cat.new
Cat.name = "Garfield" 

puts garfield.name # "Garfield" Congrats! You've made a new cat!

Instance variables have two methods. The first method takes in an argument and sets that argument equal to a variable. The second method is responsible for reading or getting the name. The instance variable is called using the @ symbol. This assures the attribute or in this case the name can be used to give other cats names, not just the object Cat.
Instance variables are basically containers for attributes of the object, which is the topic of Object Oriented Ruby Concepts Part 2.