Tiqqe People

The importance of code ownership

In Today’s post I’m going to speak about why owning code or, more in general owning a part of a project, has a lot of benefits, but I won’t do it by giving a correct definition of what code ownership is or describing the several ways you can use it: I will do it by sharing my personal experience. 


When I graduated some years ago, my dream was becoming a digital nomad. Going around the world with my computer, working from anywhere and whenever I wanted, felt it was the best way of doing this job. With the passing years and a lot of new experiences made, I realized that I preferred to settle down somewhere so I abandoned the idea of being a nomad but not the idea of freedom in doing this profession.  

When Sweden was hit hard by Covid-19 and we started to work from home, I started to realize or actually to see clearly how much time I spend working in a week and much impact that has on my free time, on my personal life. I started to feel I was in a cage and to think that after all, I was not learning as much as I wished.
At that time we were working at the migration of an old system to AWS. My tasks were a bit everywhere and they were not so interesting or challenging. I started to look at the clock and to wait for my eight hours passing. I was sad and without motivation. I was in the middle of a crisis. 

Stuff completely changed when we decided to split the whole migration in single features migration and I got the ownership of one of them. I became the owner of a part of the project and suddenly I had the responsibility of going to production with that. My life at work was completely twisted: I started to plan, schedule meetings to get requirements, discuss with the client, make decisions about code and architecture, make sure to share knowledge about the feature with my team, make sure to properly test the implementation and make sure to release the feature. My productivity just skyrocketed, as well as my level of satisfaction at work.

Finally I was working on a project that I felt was mine. I was part of something I would have been in also in my free time. I was learning and improving my skills exponentially. Finally I was feeling like I was an independent developer and not only an employee. I got my freedom back.

Therefore, code ownership is not only about owning a module, a function or a file for “agile” reasons but it is also and above all, something that every developer that needs more freedom should ask for. I think it is something that is more important and useful for the developers than for the companies, the clients or for the project itself.

Last week we released the feature on the first pilots and I cannot be happier for that. 

Development

My experience with a coding bootcamp

It took me a long time to figure out what I wanted to be when I grow up. Thinking back on the things I have considered, the common thing seems to be that I want to create. I have studied textile design and packaging design and at some point I wanted to be a baker or work with movies, you get the picture. Then two years ago I had to really rethink my working life and decided I needed a new challenge, a new start. That’s when I surprised both myself and the people around me with realising I wanted to become a developer. 

After a rigorous application process with tests, two interviews and a letter of motivation, I got accepted to a 12 week bootcamp in C#, with the promise of a job after graduation. It was a scary step to take, but I’m so glad I took it.

The bootcamp

The first three weeks were dedicated to the basics, like if-statements, loops, data types and classes, in a very high tempo. For each concept we would get a short lecture followed by related coding tasks. In those first days we could run through 5-6 new things every day. At the end of the third week we got our first group assignment, build a console app and of course all six groups decided to make some kind of game. My group did an ASCII Battleship game and even though it wasn’t pretty, it was so gratifying to make something that worked! 

After that every week we tackled a new subject, like SQL, Entity Framework and MVC. Now and then we would have a one-day focus on something like UX, Scrum or RegEx, along with lunch and learn sessions about softer skills, like communication and consultant behavior. One day we got to build a simple html site in pairs as an intro to git (with the goal to solve as many merge conflicts as possible).

Every week ended with a checkpoint, a test to make sure that everybody kept up with the pace. For some that sounds scary, but to me they were a great confirmation that I took in the knowledge for that week and could spend the weekend getting ready for a new week of information bombardment. 

During the last two weeks we did our final graduation project to tie all our new knowledge together in an actual product and at the end we had to present it to a panel of industry people. The project was just as much about working in a team and trying to work within Scrum as it was about the code. After that, we got to toast as graduated developers.

Now over a year later, these are some of the things I find myself reflecting over. 

Lifelong learning

I knew from the start that I would not know everything at graduation, rather I would know enough to get started as a junior developer and continue learning on the job. For me one of the greatest things I took away was the knowledge that I can learn anything. Even though the bootcamp was mainly in C# I could confidently say “not a problem, I pick up things quickly” in an interview for a position that was not C#. 

Peer-to-peer

We practiced pair-programming and were always encouraged to help each other out. For me explaining something to someone else will help me cement the knowledge in a much better way. It also created a great team-feeling where we all wanted success for each other, and no one was afraid to raise their hand and say they didn’t understand something.

Soft skills

Like I mentioned we were also coached in other areas needed to be a successful developer today. For a junior developer it can be those other skills that are going to set you apart from other developers with more experience than you. Because in the end it’s not always enough to know the technical part, speaking with customers (in a way they understand) or being a good teammate can be just as important.

Is it better than a university degree?

No – it’s just a different way to become a developer.

For me it’s two completely different things. In pursuing a computer science degree you gain deeper knowledge on the theoretical and high-level concept, and a bootcamp focuses on the practical skills you need to be a productive programmer. It all depends on who you are and why you want to become a developer.

#theTIQQEcode

Welcome Kevin, our new Business lead!

Who is Kevin?

My name is Kevin and I currently live in Stockholm. I have three citizenships (Canada, U.K and Swedish) but consider myself a Canadian at heart. I grew up in a little town called Alexandria (google it😊) but have lived in many places around the world, like New York, Venezuela, Korea, Glasgow, Vancouver, Halifax and Toronto. I enjoy being in new cultures as much as I can be. I have a Sambo, a dog named Seven, and am expecting my first baby in early March. I enjoy reminding my Swedish colleagues of which country is ‘actually’ the greatest hockey hotbed on the planet (yes, its Canada).

What did you know about TIQQE before you started?

I knew that they were a young, fast-growing company focused on AWS.   I have also worked with Tiqqe peoples in the past who were all high performers.

Why did you want to join TIQQE?

Tiqqe has a wide variety of skills, experience and cultures.  Whether I am working on an IoT initiative with a Senior Architect or mentoring a ‘newbie’ in how to run an agile project, I enjoy these different types of challenges that will inevitably come my way with such a dynamic group. 

Getting more experience in AWS and Cloud was a big factor and I also like the simplicity of Tiqqe’s offering. Everyone knows what Tiqqe does, what they are good at, and what they don’t do. This transparency with clients and aligned focus internally was compelling. 

What is your role at TIQQE?

Towards customers, my skills are generally used earlier on in the project lifecycle than most of my Tiqqe teammates.  Whether it’s process, policy, people or systems analysis, I analyze the as-is and identify a to-be state that addresses our client needs.  You could think of me as a Business Process Analyst, Data Scientist and/or wearing the traditional Project Management hat during implementation.  When its time to develop the solution (the hard part) I hand that over to the Tiqqe wizards and help ensure that the projects run smoothly.

Internally, I will be a part of the strategy team and am entrusted to mentor and coach in analysis and project management best practices.

What are you looking forward to in the nearest future?

Number 1 is for Corona to be over. From a work perspective, just to meet my team, get started on projects and learn as much as I can in AWS and from my teammates and customers.

Thank you Kevin and welcome to TIQQE!

AWS

The introduction of Site Reliability Engineering (SRE)

The introduction of Site Reliability Engineering (SRE) teams in the structure of an organization, is becoming more and more popular in the IT industry and in the DevOps domains.
Let’s discover in this article the reason for SRE popularity and what are the differences and the common points between DevOps and SRE. 

In the last two decades we have witnessed a huge transformation in the way of building and delivering software. The Agile culture first and the DevOps revolution later, have transformed the structure of the tech organizations and they can be seen as a de facto standard in the IT industry.

As everyone knows, IT is a constantly evolving sector and recently we are seeing an increasing popularity of Site Reliability Engineering discipline, especially in the DevOps domains. But what is SRE? And what are the differences and the common points between SRE and DevOps? 

DevOps

DevOps culture has contributed to tearing down the wall between software development and the software operation, providing a set of ideas and practices that has led several benefits:

  • Better collaboration and communication between the parts;
  • Shorter release cycles;
  • Faster innovation;
  • Better systems reliability;
  • Reduced IT costs;
  • Higher software delivery performance.

Even though this sounds amazing, there are still quite a lot of companies that struggle with bringing the DevOps culture in their organization. The reason for this is that DevOps is an ideology and not a methodology or technology, which means it doesn’t say anything about how to successfully implement a good DevOps strategy. 

SRE 

Site Reliability Engineering (SRE) is a discipline that was born at Google in early 2000s to reduce the gap between software development and operations and that was completely independent by the DevOps movement. SRE uses software engineering approaches to solve operational problems.
SRE teams have main focus on:

  • Reliability;
  • Automation.

Let’s deepen these aspects.

Reliability

One of the main goals of the SRE is making and keeping systems up and running “no matter what”. In order to achieve this, it is important to keep in mind that failures and faults can happen. SRE discipline embraces them by focusing on:

  • observability;
  • system performance;
  • High availability (HA);
  • emergency response and disaster recovery; 
  • incidents management;
  • Learning from the past problems;
  • disaster mitigation and prevention.

Automation

Automating all the activities that are traditionally performed manually is another of the main goals of SRE.
Automation and software engineering are used to solve operational problems. 

Automation plays a fundamental role in SRE: it allows us to get rid of human errors present in the processes and the activities that regard the system. One could argue that automation introduces bugs in the system anyway and well, that is true but there is one big difference: one can test automated processes but cannot test processes that involve human activities. 

DevOps vs. SRE

As we have understood, both DevOps culture and SRE discipline aim to reduce the gap between software development and operations. Below we summarize them, describing their common goal first and where they differ the most. 

class SRE implements DevOps

As mentioned earlier DevOps doesn’t say anything about how to successfully bring the culture in the organization since it is an ideology. On the other hand, SRE can be seen as implementation of the DevOps philosophy. 
In fact, even though the origins of SRE are completely independent from DevOps, and the discipline provides additional practices that are not part of DevOps, SRE implements DevOps ideas.

Responsibility and Code ownership

SRE can be considered the next stage of DevOps because of the focus on code ownership: the SRE engineer accepts the responsibility of owning the code they develop, in production. A bit different from DevOps where the responsibilities are shared to achieve a shorter release cycle and to improve the collaborations.

Conclusions

The introduction of Site Reliability Engineering (SRE) teams in the structure of an organization, is becoming more and more popular in the IT industry and in the DevOps domains. 
The reason for its popularity can be found in the benefits that the discipline brings: 

  • Better collaboration and communication between the parts;
  • Shorter release cycles;
  • Faster innovation;
  • Better systems reliability;
  • Reduced IT costs;
  • Higher software delivery performance;
  • Reducing incidents in production;
  • Code ownership;
  • Automation of the processes;

As you could notice some of these benefits are exactly the same that you will experience bringing DevOps in your organization.

SRE can be considered an implementation of DevOps culture that has the goal of making and keeping services reliable.

#theTIQQEcode

Finally 2020 is coming to its end!

  • by Alicia Hed

This year has not been as we planned. We sat together for the first time on the 2d of January in Örebro and made big visions of how this year would be. We had a great Kick-off in mid January where all employees of TIQQE set the scene for the year. We had workshops, made dinner together and it felt great! A lot of laughter, warmth and forward-thinking. February went on as planned and then came March.


In March we were heading for the Philippines. We had planned this trip thoroughly, meeting up with the team, having a kick-off in Cebu, talking about leadership and getting to know eachother better. 
A few weeks earlier we started to hear about a mystic flu that spread across asia. The afternoon and night before our departure we started to wonder if it was smart or not. The bags were packed, passports ready and movies downloaded to the iPads. Then it started. COVID.
The 13th of March we communicated to all our customers that we intended to keep our employees safe and that we would stop travel to meetings and assignments.
From that day we also started to encourage our employees to work from home.

With that said, we’ve had a fantastic year. Strange but great. When we realized that this wasn’t anything that would pass quickly we made some guiding decisions:

  • We wouldn’t back on anyone that we’ve signed up to work with us
  • If we had to do economic cuts, we would take us in the Supportgroup ( our leadership team ) first.
  • At all cost, keep our employees safe as far as we can control

So, this year we’ve employed 12 more TIQQE friends in Sweden (three starts Q1 2021) and we engaged 7 new friends in the Philippines. 
We have done a lot online. Lunches, monthly meetings, a summer party with an online escape room, and year-end meeting with reflection. We drove around Sweden walking and talking one-on-one and delivering prosecco so we could celebrate later online.
TOGETHER. 
All the things we’ve done with our employees and customers have been successful because we do it together. No one has been in this pandemic-year alone.
So when we sum this year up, we want to THANK YOU ALL. All customers for feeling TRUST in us, so we have been able to keep collaborating and develop AWESOME stuff without physical meetings & all TIQQErs for putting up with us and having the COURAGE to have faith in our way of working. Ùbúntù – we are because We are. Let’s make 2021 better than 2020 together!
Have a wonderful Christmas & a Happy New Year  

Jacob & Sofia

#theTIQQEcode

#theTIQQEcode

  • by Alicia Hed

Our Vision at TIQQE is Vision Zero when it comes to employee and customer turnover. What do we do when one of our employees decides to leave us? 

Well, we make sure that we’ve checked the following boxes

  • We’ve explored every possible way
  • It’s been a really really hard decision to make
  • It’s what’s best for the employee

In this blog we would like to share a story about our employee #5 Benjamin Bandy  who has decided to leave TIQQE. With that being said, he’s leaving us in person but never in our hearts.

Benjamin joined TIQQE just when we were starting up as a company, it was the first of september 2018.

Benjamin has been an employee and a friend who has always lived the values which are so important, he is nice, caring, sees the potential in everyone and always a pleasure to be around.

He is also a kickass techlead and developer who has always been highly appreciated by our customers. 

So why does someone that lives and breathes our values want to leave? Well, two years ago Benjamin met the love of his life. Unfortunately for us she lives overseas, in the US. For some unknown reason she doesn’t think that Sweden is a fantastic place to be (coming from Silicon Valley and working for Roblox), so in a couple of weeks Benjamin will take his belongings and move 7.921 kilometers away. 

Benjamin has been an amazing colleague for everyone at TIQQE, he has been a great friend and will be hugely missed by us all. However he has promised us to keep his Slack account so we can still frequently be in contact with him and not to forget that every friday morning at 4am he will wake up and join us for our weekly Quake tournament.

And we’ve created a mini-Benjy that we’ll keep in the office until you come back.

Even though he will be a few more kilometers away from us he will always have a special place in all our hearts. We wish you all the best Benjamin and hope that you come home soon! 

Jacob & Sofia

People

Joakim Akterhall joining TIQQE!

  • by Alicia Hed

We want to welcome yet another awesome developer to our TIQQE family

Joakim Akterhall a.k.a Akke will be joining us at TIQQE early January. He’s not only known as one of the world’s best players in Dota 2, he’s also a recognized developer. Of course one might be curious on why Akke wants to join us, so we asked him exactly that. 

How come that you wanted to start at TIQQE?

  • I’ve been working as a private consultant the past 1,5 years but I missed being a part of a company for a longer time, to be able to see and help the company grow and build relationships with both co-workers, partners and customers. I looked for a company with an interesting product that I believe in and that I can be proud of saying that I work with and where people seemed very friendly. And it looks like TIQQE has all this which makes me very excited to start working here!

What are your expectations?

  • The expectations are mostly on myself, to get familiar with AWS and be able to perform and give value to the company. In the long run I’m looking forward to extending my knowledge about AWS and learning more programming languages and frameworks.

We all look forward to Akke’s start!

People

Justine Valmores just joined TIQQE!

We’re excited to welcome Justine Valmores to our growing family at TIQQE. 

Justine is an experienced full-stack developer with a passion in developing single-page applications and mobile-responsive websites.
When at work, he develop in ReactJs, AngularJS, TypeScript, jQuery and ActionScript.
With that said, he has a great experience in front-end development as well as in back-end design. 
Outside work Justine keeps learning new web-technologies, but he also enjoys playing video games, watching TV series and anime.

Justine is part of our team for PostNord – Common Solutions.

Welcome Justine!

Development

TIQQE leadership program


Last september we started the TIQQE Leadership program. In this post I am going to tell you about my personal experience and reflections I did about it.

Change is constantly in our life. You deal with changes all the time: in your job, in your everyday life and in your relationships, with others and with yourself. 
Everything changes, everything evolves and you can’t stop that.
The only way to not be left behind, stuck in your safe bubble you have hardly built, is to embrace changes, to be a part of them. 

Embracing changes forces you to continuously question yourself and actively decide to make actions that could lead to failure, loss or even force you to start from scratch, again. And sure, that can be scary but it is the only way to grow and to improve yourself.
Embracing and being part of change is fundamental in a developers life.
In fact, IT leads the evolution and in the last two decades we have witnessed a real and true revolution in the sector.
Software has pervaded our lives and reshaped them.

The way of developing software evolved, so did the role of the developer.
Working in a team, having good communication with colleagues and customers, feeling empathy, being flexible and able to adapt, listening and supporting, being nice, depersonalizing, taking responsibilities and having leadership skills, are all qualities that a developer should have to be successful. 

Mastering one programming language to develop a certain kind of product on a specific infrastructure is not enough and valuable anymore.
What is important instead, is the attitude to never stop learning, to start from scratch again with a new technology.
Being ready and prepared to challenge yourself is precious. 
Despite the name, soft skills are not easy to master at all, and in order to achieve some of them you really need to be prepared to work on yourself.
Not all the IT companies have realized that yet and above all not all of them dare to change.

Receiving the invitation to join the TIQQE leadership program was for me, like receiving a message saying “we believe in you, we are investing in you”.
That was really nice. I got really thrilled about the idea that I was receiving a great opportunity to work on and improve my soft skills.
The program had the aim of working and practicing with some really simple but powerful tools and making their use a habit, something that is a natural part of our way to work and think.
The tools give us the ability to see different perspectives and help to work on ourselves not only personally but also in a team context and in a company context.

The best part of the experience was for me, the possibility of sitting together in the same room and speaking about ourselves. It gave us the possibility of getting to know each other, and learning from each other. I thought a lot about what my colleagues have told during the sessions we had and I tried to bring some of their perspective in my life.

I think it was an amazing experience that gave me a lot and that showed me how much I can grow and improve both personally and professionally, for myself and for the people around me.

People

Van Brigoli just joined TIQQE!

  • by Alicia Hed

We’re very happy to welcome Van Brigoli to our growing family at TIQQE. 

A full-stack developer experienced in developing softwares and web applications. Van has been exposed to working with various technologies such as  ReactJS, AngularJS, and Angular. He also has experience with Express, NestJS, Python, and Java in developing backends, while using NO SQL like MongoDB, and Relational Database like Postgresql. 

When he doesn’t work, he spends quality time with his family, or he might be seen playing online and mobile games like Dota 2 and Black Desert Mobile.

Van is a part of our team for PostNord – Common Solutions.

Welcome Van!