Forem: Elena Maroto

Why you should hire a junior developer

Elena Maroto — Thu, 03 Sep 2020 15:38:36 +0000

If you are reading this, chances are you are either a recruiter doubting about why you should hire a junior dev, or a junior dev looking for a job and thinking "Aha, at last a post that will give me hope!". I feel your pain and I'm here with you.

So, here's the thing. When you are a junior dev, whether recently graduated (from a bootcamp or other), self-taught or reconverted, it is really complicated to get a decent job. I know it first hand. I've been there. And in my case it was even more complicated because I want it all.

I was a junior dev looking for a remote job with flexibility... Gooood luck with that. 🍀

It is hard enough to find a junior dev job, let alone looking for a remote one. Luckily for us, there's Codegram. 🎉🎉🎉

About how and why a junior dev can be hired to work remotely, Elisa gives us her point of view in this post.

But I'm here to talk about why hiring a junior dev is good. Good for your business, for you as a manager or senior dev and for the poor, desperate junior dev looking for a job.

But first things first

Let's clarify something. A junior dev is not someone with knowledge in a thousand technologies, proficient in I don't know what and a thousand more requirements working for a very low salary.

That's just an underpaid job.

This 👆👆👆 is NOT a junior job. And yes, this comes from a real junior dev job offer.

By no means I am trying to say that you should only hire junior devs. In fact, that would be a disaster for your company. But hiring junior devs comes with its share of benefits.

Impressive learning curve

The good point about being a junior is that there is so much to learn. So, there is a lot of room for improvement and the learning curve would look something like this.

Although in development there is always so much to learn, the improvement is much more visible when you start as a junior dev, for obvious reasons.

A fresh pair of eyes

Yes, a senior has more knowledge and sometimes that's all you need in your project. An expert able to get up to speed fast. But sometimes you just need another look at it, a fresh pair of eyes.

Juniors are not that biased (regarding the project, the customer, the company culture or the methodology) so they are able to ask questions or even make proposals that other more senior devs wouldn't, just because it would seem stupid or obvious to them.

Sometimes the solution comes from the simplest of the proposals and that, a junior can do.

Also, some juniors might come from other jobs and have just reconverted. Their experience in other fields can bring light and a different way of thinking to the table that can be very valuable.

Get that repetitive/ungrateful tasks done

Remember that refactoring you've been meaning to do but never had the time to? Or simply you just thought it was boring and you wouldn't learn anything new? Well, your junior dev could use some of that!

Being a junior means that almost everything is new and the most boring task for a senior could be a whole new improvement field for a junior.

Like, e.g. we've taken advantage of summer time and students holidays to reorganize our Graphql resolvers in Empresaula. Sure, after you've done it 50 times it doesn't bring anything that new to the table, but I for sure have learnt a big deal and had to deal with many issues that I wouldn't have faced otherwise.

So, it is a win-win. You get that long-awaited task done and your junior learns a lot!

Educate them into your company culture, methodology, etc.

If your junior is fresh-off-school, then the field is green all over. They do not have any previous experience, bias, etc. That doesn't mean they don't have an opinion, but they have less to compare to, and they are more willing to get guidance and follow procedures, etc.

If your junior has reconverted, it means you have someone in your team who most likely left a stable job, maybe even a well paid job, to become a developer. They were even possibly a senior in another field. That's big. Making such a change is really difficult (I know it first hand). But it also means that this person is able and willing to adapt, to learn and to question themself. So they can not only embrace your company culture, but also bring fresh ideas to the table. That has a big value.

It's cheaper and less risky

As I said at the beginning of the post, a junior dev post shouldn't hide an underpaid job. I cannot stress this enough: Experience has to be paid.

That's why hiring a junior dev is cheaper. In exchange, and if you want this to be rewarding, you need to invest in them. Mainly in coaching and technical training. Otherwise, you could end up with a junior forever. And nobody wants that. Not you as an employer and for sure not the developer. Every person wants to evolve in their job. Help them do it and you won't be disappointed.

Think of a junior dev as a longtime investment. If you take the time, interest and right approach with your junior dev, you could get yourself a very loyal, very productive employee.

What about the risks? Well, you could argue that you might educate them and they would fly away. Yes, that is a possibility. But so can your senior devs. If this happens, the effects of having a junior vs a senior leaving are way less devastating.

Ultimately, it is up to you to make your employees happy so they want to stay with you. And happiness at work is not foosball, free coffee or casual friday. There's way more to it.

There are many other benefits to bring a junior dev to your team, but the main point of this post is to show that a junior is not only someone without much experience, but someone with a lot of potential. And that is what you should be looking for.

The key to greatness is to look for people's potential and spend time developing it. Peter Drucker.

Angular for Junior Backend Devs

Elena Maroto — Mon, 22 Jun 2020 14:00:48 +0000

So, by now you know I'm a junior web dev, right? If you don't... well, look at my previous posts, there are a few references there.

Now, I'm not sure I've clarified this, but I am backend at ❤️. Like, from the day I was born (job-born). In my previous job as a developer I was developing in ABAP which is basically SAP's backend own language.

I like the logic behind backend and I like specially the connections between systems, APIs, events, etc.

Then I switched to web development and got trained as a FullStack dev. But still, my heart belonged to backend. Don't get me wrong, it still does, but let's say at Codegram I've decided to give frontend another chance.

The first misconception that we backenders often make about frontend is that it is only about HTML and CSS. Placing stuff in the page and making it nice can be a bit of a nightmare. Also, there are soooo many possibilities that you can literally spend your day trying stuff and getting nowhere. Or that's at least my feeling and experience with those two.

Anyhow, so I decided to give another go to FE, mostly because I had to work on some stuff in Empresaula and because... why not?

As you might also know from previous posts one of the widest used frameworks at Codegram is Angular. Not easy, I have to say! But it is nevertheless interesting.

I can't say I know how to work with Angular back and forth, but I've got a few notions that might be interesting specially if you are a junior and just getting into it.

Let's dive in!

The first thing I was looking for when starting to learn Angular were the basics, like the very very basics, the architecture, how does it work and who talks to who. And this is what this post is all about.

Needless to say that it has been complicated. The Angular learning curve is steep, to say the least, but with a bit of patience and going over the training about a thousand times can help...

First of, what is Angular?

Angular is a framework for building client applications using HTML and TypeScript. Angular is written in TypeScript. It implements core and optional functionality as a set of TypeScript libraries that you import into your apps.

The Architecture

Let's have a look to the basic elements of an Angular application.

From Todd Mottos' Angular Fundamentals course

Modules

Angular apps are modular and Angular has its own modularity system called Angular modules or NgModules.

Angular modules are a big deal.

Every Angular app has at least one Angular module, the root module, conventionally named AppModule.

A module is a main building block of an application. We can have a single module, we can have multiple modules and we can have modules that depend on other modules.

A module can contain components (like a feature component), services (like a service tied in with that particular feature) and routes (to decide which URL to go to in our app).

E.g. in an email client app, each of the three boxes below would be a module.

From Todd Mottos' Angular Fundamentals course

Components

A component contains an HTML template, the data and the logic. It also forms part of the DOM tree. Components can be linked to other components.

From Todd Mottos' Angular Fundamentals course

There are two different types of components:

Container components (also called stateful or smart). These guys will contain data and render stateless child components.
Presentation components (also called stateless or dumb). These guys will communicate with their parent container component through the @Input and @Output property bindings.

A component can have services and directives linked to it.

Directives

When Angular renders a template, it transforms the DOM according to the instructions given by directives.

A directive is something that we can bind to an existing DOM element, an HTML element or a component. It can add behaviour and extend or transform a particular element and its children.

Angular has a lot of built-in directives. Examples are ngIf, ngFor or ngRepeat.

Services

So now, we have structured our application, we are able to change our DOM with directives, but hey, where's the data?

Well, well, well, that's what services are for!

The service is basically where we will include any value, function or feature that the application needs and that it is not component related, such as e.g. API requests.

Imagine that we want to fetch data through an API, we'll pass it into the component, the component will render that data, we can make changes in the view and update the data in the backend. Both the fetching and the update logics would lie in one or different services.

A service can be tied to a particular component to give it the data that it needs.

What about routing?

Well, simply put, routing is the guy that drives the navigation in our application.

This guy will tell Angular which components to render based on the URL state.

Here's an overview of how all these elements work with each other.

After some days both fighting against and learning a bit about Angular, I must say I am willing to continue diving and learning more frontend. Yes, there is more to it than just HTML and CSS.

I find specially interesting the way each part of the puzzle interacts with each other. There are lots of events involved, and I told you I like events, so that's already something!

Sure, Angular, is not the easiest way to get into it, but now I can only wonder about e.g. Vue.js. Maybe that'll be my next stop, who knows?

Cover Photo by Alev Takil on Unsplash

The Way to a Tight Knit Remote Team

Elena Maroto — Fri, 22 May 2020 11:09:26 +0000

If you've been following Codegram for a while, you must know by now that we are a remote first company.

That doesn't come without challenges, but that's not what I want to talk about today. Instead, I want to give you some insights about how Codegram works as a remote company and how we keep the team spirit going.

Start with why

(Why I'm doing this post, not why Codegram is a remote company. Sorry! 😅)

So, the why is a nice comment I received today from my colleague Svenja (you know her, she's the one in love with RegExp 🙄).

See, one of the nice things we do every week is meeting for coffee with one or two other people, and then our friend Donut asks for a nice comment on it (spoiler: Donut is actually an app). I admit I am bad at leaving those comments (I don't know, I feel cheesy and I would most certainly cry while writing them... don't ask), but aside from being useless at that, it is always nice to receive a message from someone else. My dear colleagues, take this both as a thank you and a sorry. 🙏🏼

So, that's it. I received a nice message from Svenja (she made my day) about our last coffee and then I thought of the nice things that make us feel connected in this company and that I enjoy so much. And I thought it would be nice to share it with the world out there. Sooooooooo

First, the non-work stuff

Cause, you know...

The Codegram Times - This might be classed as both work and non-work related.

It is first in line because it comes usually on Monday and to be honest, it makes me start my week with a smile on.

Georgina, our office manager, prepares every week a curated bulletin in Notion. It starts with a culture note, then goes on with inputs from tech leads on advancements during the previous week, then she shares some off-work stuff from team members. This could come from twitter, private conversations or from our Telegram "Offwork" group. And you learn pretty interesting things about your colleagues that way! (Don't worry, she always asks before publishing.)

The Times ends with one or two questions like "What are you reading right now?" or "What is your favourite smell?". And we can all participate with our comments afterwards. It is very entertaining!

I know for a fact that I'm not the only one who starts the week smiling thanks to this.

Coffee-buddies

Another great thing to keep the team connected.

See, when you work remotely you don't have a coffee machine where you can chat about everything and anything, so you gotta do something right? So we've set up Donut for Slack.

Our friend Donut pairs up 2 or 3 people every week and then you schedule a short meeting of 30 minutes... just to chat. This is a very nice thing to do, cause it allows you to meet your peers wherever they are.

Then Donut asks for a comment on how it went and... well, you know the story.

Tacos! Tacos everywhere! 🌮

Have you watched "Cloudy with a Chance of Meatballs"? At Codegram is "Sunny with a Chance of Tacos".

So, here is the thing. One day our Engineering Cheer Leader (or CTO for short) decided (don't ask why or how) that it would be a nice thing to offer tacos here and there. Oh, they are virtual tacos, but they are so fun!

Your last blogpost was a hit? 🌮 You helped someone else figure out something and unlock them? 🌮 You learned something new and shared it? 🌮 You get the idea. Tacos! Tacos everywhere!

🌮🌮🌮🌮🌮🌮🌮🌮🌮🌮🌮🌮🌮🌮🌮🌮🌮🌮🌮🌮🌮🌮🌮🌮🌮🌮🌮🌮🌮🌮🌮🌮🌮

We're out of tacos for now, but I know for a fact that there are more in the making.

Off-work Slack channels

Because not only of work the man lives (pun intended... I know, I know... 🙄).

We use Slack mainly for work (did I tell you we work as well?), but we have a few off-work channels to, you know... not work.

Examples are:

health-and-fitness - fueled by love handles 100%

jukebox - 🎶 Share your best jams!

random - General banter

languages - A channel to share resources about learning new (human, non-programming) languages

camera-cafe - A channel for everyone to join when having a coffee / lunch or just looking for watercooler conversation ☕️

Off-work Telegram group

Another place where we keep connected off-work and off-computer.

Here you can find a little bit of everything. The last vegan recipe, the last picture of a cardboard castle built during lockdown, pics of sluggish dogs, cats, bread, bad jokes (many bad jokes). Everything goes! That is, everything respectful. R E S P E C T. Always.

Weekly company wide video call

This started during lockdown, so we could be (more) connected but I bet it is here to stay. It happens every Friday at 4 pm and every week there is a theme.

This week's theme? "Imagine that you have applied (maybe with your family too) to go to Mars and in an interview you have to say why they should select you, what you can contribute and what sector you’d like to work in". Apparently Georgina came up with that idea during breakfast... and it was really fun!

Other theme's have been, "What's something you've done in your life that you are really proud of?" or "Show and tell. Show us your favourite object and tell us why" or yet "Tell us a moment of your life when you were really, really embarrassed".

These calls make for some interesting conversation and are a very good kick start for the weekend.

And speaking of weekend, it is Friday and I'm off!!

Oh, yes, there's still the work part right? Ok, ok, I promise I'll come back with it. Stay tuned!

About programming languages

Elena Maroto — Tue, 07 Apr 2020 17:05:34 +0000

So, I've been trying to focus a little bit more on my training, being that I am a junior and all.

My current goal is to finish a chapter a day of a book recommended by our CTO "Metaprogramming Ruby". While I achieved my goal today, it has required a little bit of focus. The book seems quite interesting and concentration was good until one question popped in my mind. 💡 What other metaprogramming languages do I know?

"Metaprogramming is writing code that writes code."
Excerpt From: Paolo Perrotta. “Metaprogramming Ruby 2”.

Of course I lost concentration and I went asking almighty google. And the non-less almighty wikipedia readily answered. Well, not directly to my question but still... And I found out that there are no less than 50 kinds of programming languages!! Some of them are sub-categories and classifications from different angles but still... 50!

So I started wandering around the wikipedia classification and identified some languages I knew (oh, yes, forgot to say I'm not a "real junior". I was a developer before, but I'm a junior at web development).

While checking that, and learning more about types of programming languages, some rather nice and interesting memories came to mind. And I felt like sharing them, cause, you know...

What surprised me the most was the amount of different types. Of course a certain language can fall under different classifications, but still. I barely remembered compiled and interpreted languages from my university days. Maybe also procedural rang a bell... but that's about it.

So, here it comes. My thoughts and memories from working at a certain point in my life with some of those languages.

If you came here looking for a thorough description of all categories or a very technical-ly post, sorry to disappoint you... this ain't it. Look at it more as a recreational walk through my "programming life".

Let's start with COBOL

COBOL falls under three different classifications: Compiled, Imperative and Procedural.

This language was designed in 1959 and yes, my friends, I've used COBOL. It was back in... oh gosh, it was so long ago that I would need to calculate the dates... Anyhow, I remember it was before university, at technical high school. And I remember writing code one day, leaving it compile overnight, coming back the next day and finding out the results of either the execution or the errors printed in a gigantic perforated-paper printer. Yes, I am that old...

You can imagine how complicated that was. We were doing small simple programs, we were students but still, a small mistake would mean having to wait yet another day to have the results.

It has obviously evolved over the years and since 2002 it has become an Object-oriented language since then.

Next in memory lane is ADA

ADA falls yet again under many classifications: Compiled, Concurrent, Imperative - Procedural, Multi-paradigm, Object-oriented and System programming language with manual and deterministic memory management (no link for this, sorry, look it up 👀).

The only thing I remember about ADA is that it helped me pass my Operative Systems exam in my last year of university. I remember it was a simple language (it might be because of OO). And I remember telling my friends that studying ADA could actually save us from failing the exam. I thought of it as a low investment high ROI. Turns out it was a good strategy... for me. Many of them didn't listen... and failed.

Lets talk about C

Not that I like C, in fact this is the only subject I dropped in university. I simply hated it. My sister though, loved it. I remember having to write some code to simulate a typewriter. Having to manipulate all the memory directly and all that complicated stuff, I just simply couldn't stand it. Always found it way too complicated. Hate, hate, hate.

C is also Compiled, Imperative - Procedural and System programming language with manual and deterministic memory management (did you look it up before?).

I'll skip a few years and languages, cause I guess you have a life and things to do other than reading this, right?

Let's move on to ABAP

This is an easy one, only one category. As it turns out, ABAP is a 4th Generation language (4GL). I didn't even know that existed...

ABAP is the language created and used by SAP. The all-mighty says "It is extracted from the base computing languages Java, C, C++ and Python", but I would have compared it (at least in the first years) with COBOL... but what do I know... I didn't even like C!

Do I like it? Well, I didn't dislike it, to be honest. I worked with it for about 20 years, so I guess the answer might be yes. It is the only language I've actually used professionally (other than Ruby), so I don't think I have much criteria to compare. Or maybe I do...? 🤔

Ruby. It's a wrap.

In the end this is the language at the origin of this post. If you are a web developer you most likely know Ruby. If you don't it's never too late.

Did you know that Ruby is an Functional (impure), Imperative, Interpreted, Object-oriented, Meta-programming language? Well, know you know.

I found learning Ruby was easy. It took a while to get used to the fact that so many things where just so easy to achieve. At the beginning of my training I would develop methods to do simple tasks to later on learn they already existed. Now, I am learning that most of those methods exist thanks to Meta-programming which seems fascinating to me.

Well, well, well, after all these interesting facts it is now time for me to go back to learning. There's so much to discover! Ups, almost forgot! Check out the wikipedia link that brought me here!

What are your favourite languages? Any memories worth sharing? We would love to hear about it. Share your thoughts in Twitter.

Git is your friend

Elena Maroto — Wed, 18 Mar 2020 17:31:57 +0000

I think we should rename the periods in BG and AG. Before Git and After Git.

I haven't lived the BG period, as I was not working in web development, but I can only imagine how complicated that must have been.

It's like when I think about the good old days when the web wasn't everywhere (yes, there was a time...) and we had to go check a book (like, a real one, in paper and stuff, and usually very big) to solve our programming questions.

Ah those times... there was something about it...

But let's focus on what brings us to this post today. Git.

Starting from the bottom. What is Git?

Git is one of many VCMs (Version Control Managers). And why do you need one of those, you say? Glad you asked. 🤓

Imagine this situation:

Jenny and Meryl are working on the same project. They are working on different features. Both features use the same table and so the same DB methods. Then Jenny needs to make a change to, lets say, the update method. At the same time Meryl needs to do a different change to the very same method. Both need to happen at the same time, and both are working on the same code, each on their own. So, how do you handle it? How do you ensure none of the changes get lost on deployment? Well, my dear developer, the answer is... 🥁 you've guessed it... by using a Version Control Manager! 🤯

Situations can get waaaay more complicated than this (imagine several people working on several features at the same time), but for the sake of simplicity, we'll leave it here and move forward.

Let me introduce you now to your newest friend: Git. 🎉

Do you know what Git means?

Well, I started looking online hoping for some kind of acronym, you know, like FTP, HTTP, etc. which actually mean something... and well, nope! As it turns out, Git was named like that by Linus Torvalds, who, you've guessed it, is the creator of Linux.

Git is actually slang for "unpleasant person" (go figure 🤷🏻‍♀️) and Torvalds would joke about this saying: "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'Git'."

The name "Git" was given by Linus Torvalds when he wrote the very first version. He described the tool as "the stupid content tracker" and the name as (depending on your way):
- random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of "get" may or may not be relevant.
- stupid. contemptible and despicable. simple. Take your pick from the dictionary of slang.
- "global information tracker": you're in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room.
- "goddamn idiotic truckload of sh*t": when it breaks

Extract from Wikipedia's Git page

What's all the fuss about?

Well, if you are a web developer you are most likely using Git... but maybe you don't really know what its benefits are. Sure, there are other version control managers, but Git has become the leader in the last few years, overrunning market leaders like Subversion.

How did this happen? Well, there are a few main differences between Git and other VCMs out there that account for its success:

Git is a distributed system. The main benefit being that you can work locally. Other VCMs require for you to be connected to the central repository while working. Git, on the other hand, allows each contributor to make a copy of the project and work on it on their own machine. They'll only commit changes to the remote repository every once in a while. Which brings us to the second benefit.
It's faster to commit. For obvious reasons. Since you are committing locally most of the times, commits are faster, no network traffic issues.
It's available offline. Which means you can work on your code anytime, anywhere. Connection or not. You can even code while on a plane and use those long flight hours to your code's advantage.
There's no single point of failure. Meaning, if the remote repository breaks, you can still work on your own until it gets fixed... and then commit your changes to it.

Isn't Git too complicated?

Well, it can feel a bit like a black box at times. The reality is though, that Git is just an addressable file system. Everything we do can be broken down to simple operations, even done by hand (that would be more complicated, but it's still possible).

Let's now dig just a little deeper, shall we?

The basics of the basics

When working with Git repositories your data goes through 3 different stages:

Working directory - The root directory of your project. Any additions, changes and deletions of files and directories done here that aren’t tracked, won’t make it into the repository.
Index - Also known as “stage”, is where you decide what changes should go into the next commit. This is what you actually update with the Git add command. Sounds familiar?
Repository - This is where the actual data goes and all commits, branches, tags and other things are stored.

And more...

All of our data, changes and commits are stored as hashes on the file system.
It is rather hard to lose work with Git. Even if we don't create commits but simply add our changes to the index, Git will already store those changes, making it complicated to lose them.
With Git, every single change and commit can be addressed separately thanks to the hashes.
An entire commit history can be restored with a single commit as long as all references are in place.
Git comes with a built-in garbage collector that will remove any Git object that isn’t reachable by any branch or tag.
Git offers different merge strategies for different scenarios (e.g. three-way and fast-forward).
Merges can be undone and cancelled.
With interactive rebase, Git offers the possibility to reorder, split, squash, delete and choose the commits you want to merge to your main repository.
Git allows to run a program after a commit has been replayed during a rebase.
Cherry-picking allows to pick any commit or range of commits in our repository and apply it on top of other commits.

My personal experience with Git

I had been using Git in my personal projects and while this is good and useful, it is by joining Codegram, a web development company where Git is widely used, that I really could appreciate its benefits. All of a sudden things like rebase make way more sense, and working in a team make you realize how complicated our lives could be without Git.

Still hungry for knowledge? You want details? You want commands? You want to play with it? 🤙 I feel you. 👉 Then by all means go get hands on with the book that inspired this post: "Rebase" by Pascal Precht.

Photo by Krista Mangulsone on Unsplash

Routines for a routineless life

Elena Maroto — Tue, 11 Feb 2020 12:46:27 +0000

All along my working career I have never been able to make it to work twice at the same hour. Ever. In 20 years. That's a lot. Luckily I hadn't had to clock in or out in any of my jobs. I didn't like taking the bus to work either, cause of the fixed schedule.

Yeah, you've guessed it. I don't like fixed schedules. My brain (as in a separate entity from my own self that I can blame) doesn't like to deal with that.

Then, about two and a half years ago I quit my big group job. Bootcamp, holidays, everything was ok.

And then January arrived. No fixed schedule and all the time in my hands to start my own business. I could do whatever I wanted whenever I wanted. Everything was going to be birds chirping and flower smelling.

But you won't guess what happened.

I was lost. My little brain didn't know what to do. I felt unproductive all the time, while feeling that I was working all the time.

I also felt guilty for doing things like going grocery shopping on a Tuesday at noon when there's basically no one (cause everyone is at their 9 to 5 jobs). My little brain thought that at that time I should be working... like I'd been doing for the last 20 years!

How is that possible? How come I am feeling this way if this is exactly what I wanted?

I was blocked and felt I needed help. So after a friend's recommendation I worked with a coach. It only took one session to address the issue.

"This is a common problem with people who change from a fixed schedule job to a flexible job", he said. "The problem is, you have removed the frame that your brain was used to follow for the last 20 years and now it doesn't know what to do. You need to set a schedule."

I'm sorry, did you just say a schedule? No, no, no, ain't gonna happen. I hate schedules!

But I figured, since I was paying him (a lot) to give me advice I should at least give it a try.

Fast forward a couple of years.

Now I am working at Codegram. Remote job with flexibility. Perfect!

In parallel, I am working part time on my own business that I've created during the last 2 years. That, my friend, requires organization... and schedule.

The good part is, it is you who sets the schedule. It is you who decides your working hours. You organize your job around your life and not the other way around.

But still, you need to be very careful to not end up working on the couch in your pj's with your TV on (true story). Cause if you do that, chances are, you are not going to be productive. And you want to be productive, right?

So here are a few things I've put in place since I started my full time job at Codegram that have worked for me. I usually work from home, though sometimes I'll go with a friend to a mall where there's good wifi, or go to a coworking, depending on my mood and needs.

These tips are taken from podcasts, articles on productivity, etc. I did a mix and match, tried and found (so far) what works for me. Hopefully this will help you as well.

👉Enter "Routines for a routineless life".

I go to bed and wake up at a regular time everyday. I am not a morning person, and I like to stay up late, but if you do that, you go somehow against the world. So, a little arrangement here and there helped with that. To my surprise, by keeping the schedule regular, I even wake up somedays before my alarm goes off.
I hit the gym 3 times a week first thing in the morning. Another thing I had a hard time sticking to. I read somewhere that you should get the most complicated task over with first thing in the morning, that way, you've won your day. I don't know about the wining your day thing, but for sure this has helped me keep up with my exercise routine... which is a lot to say. The trick? No discussion with my brain. I go to the gym. Period. There's no room for negotiation there.

I work for 2 hours on my own business. On days I don't hit the gym, I work on my business first thing in the morning.
After that, and only then, I take my shower and get ready for my Codegram job. This might seem stupid, but I get dressed as if I would go to the office. I even put on my earrings (I never go out without earrings, I feel naked without them when I'm not at home... don't ask why, 🤷🏻‍♀️everyone has their weirdnesses...). My business and my job at Codegram have absolutely nothing to do one with the other, so my brain needs sometime to switch between activities and allow full concentration in both of them at their own turn.

The simple fact of taking a shower at this time and getting dressed to go to work tells my brain that I am switching activities.

When it comes to lunch, I usually cook on the weekends, normally a couple of simple lunches with several portions, so I don't have to think about it day in and day out. Then I have lunch watching something easy on tv or just looking at the ceiling... basically not thinking about anything... (or that's what I want to make myself believe...).
When my workday ends, I "go home". Meaning, I change my clothes into my cozy, warm stay-at-home-wear... (and take off my earrings!). That tells my brain that my working day is finished.
I keep track of my worked time. Not that it is a requirement at Codegram, but I want to make sure I don't go way overtime, which is very easy when working at home. I use toggl.com for that.
I have different working spaces for my two different activities. For my own business I work on the island counter in my kitchen (don't worry, it is comfortable). For Codegram I work in my office (which is set up in my guests room).

This is also valid if you have only one activity. Having a distinct, separate workspace helps your brain separate between work and personal life.

This is all in all what has worked for me so far.

Surprisingly, and much to my little brains regret, I feel much calmer having a schedule and sticking to it.

Still, I allow myself for some flexibility when needed (grocery shopping, doctors appointment, lunch with friends...), that's the beauty of a remote, flexible job, isn't it?

What works for you? Tell us on twitter. And follow us, while your at it!

DevOps for Juniors... by a Junior

Elena Maroto — Fri, 17 Jan 2020 19:00:00 +0000

So you just landed your first Junior Web Development job. Yay!

Say you joined Codegram. Double Yay!

And you start the onboarding process. 😱

Everything is very well explained, the tone is friendly and nice, step by step, everything is going smoothly... and then you make it to the technologies part.

Wait, what???

You are a junior 🐣. A tiny little web-baby that just came out of her tiny little web-crib and started to make her first tiny little web-steps. In your web development bootcamp you used what? 5, 7, 10 different technologies? And at Codegram we use like, how many? A thousand??? (exaggeration alert❗️).

Ok, let’s stay calm 🧘🏻‍♀️. So I know about frameworks (more or less), languages (more or less), databases (yes, I know what a DB is… does that count?), frontend , backend , API … I can deal with that. But what about the systems part? How does it work? Mmmm, I feel like deepening a little bit into DevOps today.

I’m not really a DevOps person, but I want to have an overview beginning to end of what and how is happening, otherwise my brain goes like:

So, let's start. I’ll filter by “Systems”: Heroku, Docker, Kubernetes, AWS.

Oooooook now. 🤔

I know what Heroku is, right? - “Heroku is a cloud service provider and software development platform which facilitates fast and effective building, deploying and scaling of web applications. It has 140 inbuilt add-ons, ranging from alerts to analytic tool security services which are used for purposes like monitoring, caching and mailing or networking add-ons.”

Crystal clear. Basically it's where I’ll deploy my application, my server in the cloud. So no need to care for physical servers and operations. Heroku is easy to use. This is the basics of the basics of deployments.

Aaaaaand here is where my DevOps knowledge ends! 🤷🏻‍♀️ Moving forward...

Hey Docker! What do you do in life? - “Docker is a tool designed to make it easier to create, deploy, and run applications by using containers. Containers allow a developer to package up an application with all of the parts it needs, such as libraries and other dependencies, and ship it all out as one package. This allows for the application to work more efficiently in a different environment.“

Love the (mad) Linux penguin!

So, for juniors now. With Docker basically I’ll get my application, create a package with everything and then manage and ship everything as a whole. But where? Well, I could ship the docker containers to Heroku… but not only.

Meet Kubernetes! - “Kubernetes provides you with a framework to run distributed systems resiliently. It takes care of scaling and failover for your containerized application, provides deployment patterns, and more.”

“In other words, Kubernetes is a container orchestration platform.”

“Kubernetes can run without Docker and Docker can function without Kubernetes. But Kubernetes can (and does) benefit greatly from Docker and vice versa.”

Junior translation. You have your application, that you’ll package in Docker containers. You can run and test your application locally with Docker. Then you ship your containers to Kubernetes. Kubernetes takes care that your application is running all the time with load balancing and all. Easy right?

And what about AWS???

Ok, so, without surprise, AWS is like the God of the Cloud Services.

Want virtual servers in the cloud? AWS EC2. Want to deploy code without thinking about servers? AWS Lambda. Want to deploy Docker containers? Yep, that too. AWS ECS. Blockchain, NoSQL Databases, IoT, Machine Learning, you name it.

So, when should you use what you may ask? Well, sorry to disappoint you… I am just a junior dev…

Good news is, you can check with my senior colleagues at Codegram! Throw us a line at hello@codegram.com and we'll be glad to help you!