Forem: Stathis Georgiou

Bite-sized advice: Imposter Syndrome

Stathis Georgiou — Sun, 11 Feb 2024 20:30:02 +0000

If you spend half of your day wondering if you deserve that new role you just landed or questioning your manager's decision to make you lead that huge project, welcome to the club!

Your subscription to the "Imposter Syndrome" magazine is here! New issues are out every day, reminding you how much "not-enough" you are about everything. Enjoy!

You are not alone.

Jokes aside... I hope it helps you know that most people go through these feelings sometime in their careers. Especially if you want to grow you will find yourself in that situation every 3-5 years.

But because we all are having the same issues doesn't mean yours does not matter, on the contrary! It probably means that these issues are a real problem but also that you can get different advice on how to fight them.

Practical advice

Talk about it.

If you feel like a fraud, talk about it with friends, family or colleagues. Saying out loud what is on your mind helps you debunk it. Most of the time imposter's thoughts are saturated and completely made up. So when they are spoken and materialized is easy to be seen as what they are, imaginery facts to prove something that is not there.

Create a list of successes.

Next time you get the new issue from Imposter Syndrome magazine, read it, talk about it, and then write a letter back to the author explaining why you disserve what you have. In the letter, try to introduce yourself with your full title, and then talk about what you have succeeded in the past. Write down a numbered list of all the things that you have achieved that lead you to the current status you are in. Save that list and stick it somewhere easily accessible. This will make you fight against imaginary thoughts with an arsenal full of concrete facts. The thoughts will not stand a chance here.

Ignore it.

Ignore the thoughts and lose yourself in the tasks. Last but not least, maybe even my favorite one, is to ignore the imposter syndrome issues altogether. Let the current task, whatever is in front of you at the given moment, be your main focus. Let the thoughts of feeling a phony come and go, dissolving them with your actions, proving to yourself that you can do the job and deserve where you are. Beating the thoughts with actions, and realizing that they are just thoughts, weakens them in the long run!

Conclusion

These three actionable pieces of advice are not meant to magically work for everyone, but I strongly recommend trying them out for some time. You also have to experiment and find out what works better for you. In any case, do not let the subscription to these harmful thoughts keep going unchecked, monitor your mind and cut down the costs to the minimum.

Start by sharing your successes in the comments!

Photo by Gus Ruballo on Unsplash

How to adjust fast to a new codebase

Stathis Georgiou — Fri, 09 Feb 2024 12:38:55 +0000

New codebase

With software development skills in such high demand, the opportunities are plenty. With the right combination of determination and patience, anyone has a chance to make a start as a developer.

There are multiple articles on how to land a new software developer role and even more tutorials to acquire the knowledge to do it.

After you land a new role, though, you are pretty much on your own. The trial starts, and you will be judged and tested on how much value you can add to your new team/company. The good news is that most companies out there will show a lot of understanding to new joiners as it is widely accepted that everyone needs time to adjust to a new role. On the flip side, most companies don't have a plan to introduce you to the new codebase, and you will most likely be merged into the team slowly by solving tasks and figuring out things by yourself.

You will be faced with many new challenges, and needless to say, most of them will be around the new codebase you were hired to work on.

This article will give you some ideas/suggestions on how to familiarize yourself with a new codebase and also how to start adding value to your team as soon as possible. A strong start and the ability to adjust quickly can also mean a lot for your progress in your new company.

I will attempt to break down the ideas into three different areas, as I consider the adjustment to the new codebase a multifaceted process. It will make the article easier to extract useful, actionable methods that you can start applying in your current role. In the first area, we will focus on your attitude as a new member of a team. The second area will be about how to gain a deeper understanding of the new codebase/system. And for the last part, you will get some insights on how to familiarize yourself with the new tools that will be your companion in your new journey

Attitude

Question everything (silently if you have to).

As a new member of the team (with a lot of knowledge missing and yet to be acquired), you are forced to rely more on other people's knowledge. It makes sense to do that as you try to navigate yourself through new challenges.

The danger with this approach is that it is easy to take as a fact every bit of knowledge shared by your more experienced team members. They will intend to help as much as they can (most of the time), but even with the best intentions in place, they are people too, and they make mistakes. If you just rely on that shared knowledge and take it as the absolute truth, apart from the fact that this piece of information may be inaccurate or even wrong, you also miss the chance to form your own opinion. It will be crucial for your understanding to analyze everything that is lying in front of you. With that exercise, of constant investigation and validation of the information at hand, you gain more knowledge of the codebase.

It is also valuable to the team to have a new perspective on how they do things, and even more, you can come up with suggestions of your own. This will show that you have the ability of critical thinking and that you value the software that you work on.

That being said, you have to be very mindful of how and when you express these fresh opinions of yours. Every team has its dynamics, and as a new joiner, you have to respect them and challenge them with a gentle approach. In an open-minded team, where there is space for everyone to suggest changes, your questioning of everything will be welcomed. In a more inflexible team, you will need to work on your way of bringing that value.

Ask questions

It is not a rare attitude in a competitive workplace to want to hide your weaknesses as you try to climb higher in the hierarchy of a team. It is hard to admit that you don't know something that everyone else seems to understand and talk about with ease. You can be an experienced developer that does not want to show that you lack knowledge that a junior developer has, or you can be a junior that is afraid to show you are not experienced yet (that is a feeling that happens at all levels, in my opinion).

Software engineering is a learning process. You have to battle the fear of exposing your ignorance through a question. A good student is not only a student who has the curiosity to learn more but is a student who, on top of that, is not afraid to ask stupid (and frequent) questions. We are all students when we are new members of a team.

The easiest way to find an answer to something you don't know is to ask someone who does. I have been in situations where a whole project was derailed because the appropriate questions were asked too late. Be open and precise about what you don't understand so people know how to help you.

Although asking questions is essential for your improvement, it is also very important to learn how to get some answers by yourself. Find the balance between the time spent on the investigation to understand how something works and the time spent to ask questions.

Be open-minded

Every company has a different culture. Every team has different habits and protocols (if any) in place. You will need to accept that things are done in a specific way, which is probably very different from the things you worked on before, in your new team. Embrace the opportunity to find new ways of working and be open to all new experiences.

You can encounter different perspectives and ideas that will force you to rethink your old habits. Different protocols/standards/ habits, no matter better or worse, you can always learn from these.

Every new team member has to comply with the existing "rules" and sets of instructions to have a chance to become valuable and functioning in the new environment. If certain habits make you unproductive, you need to be upfront and discuss them with your team lead/line manager, always by respecting what is already in place of course.

Talk with your colleagues

One of the best ways to acquire knowledge and network yourself deep in the team is to converse with your colleagues about the system.

I am not talking about asking questions about things you don't understand here. It is more of a casual conversation with a fellow coder on what they worked on. These kinds of chit-chat can start by just asking, "Are you busy these days?" and letting the other person talk about their pains of the week. Showing interest is always a good conversation starter, find the person who built that great module you were using or an interesting feature and just tell them how cool it is, most of them will be glad to go into deeper details and share the pain points with another developer.

Deeper understanding

Read the code you are working on and everything around it

When you are called to fix a bug, alter an existing behavior, or even build a whole new feature, it is easy to focus only on the code that needs to be changed. It is possible to stroll along with your task, delivering what is needed, without fully understanding how the system works.

A better approach, though, is to read and understand what the code is doing. Try to break it and experiment with different changes. This process will give you a deeper understanding of the codebase. Even better, you can try to do the same investigation for the caller of the function you have to alter, and the caller of that caller... Every task you get is a great opportunity to investigate how the code is written and organized.

In the PHP ecosystem, the MVC architecture is very common. If there is a change you need to implement in a controller, try to also investigate the parent class of that controller. Check if there are any middlewares at play. Do the extra click to find what is under the hood. The rewards can be great. After some time, you will have covered enough code to feel comfortable.

Understand the request lifecycle

If you are working in a web application, chances are that the code is accessed most of the time through the web. The request lifecycle is a vital concept to understand as everything "goes" through some defined steps to reach the logic you are trying to work on. Invest some time to understand all the steps. Make notes or add bookmarks to the common paths of the code.

Check what packages are used to unpack the request payload or the implementation of the middleware. Check how the controller is invoked and how the data are passed around. Play around with the authentication/authorization mechanisms that are in use. Bit by bit you will be able to build a deep understanding of an important part of the system.

Understand the framework that is used

This suggestion is an obvious one, but given the vast amount of features and bugs that come to our desk daily, it can be easily omitted. If an application is built using a framework, then the framework is the most commonly used tool by a developer working on that application. We are called to use that tool to build new features and solve existing problems.

As a beginner, it was always challenging for me to make sure I was using the framework tools to solve the issue at hand instead of reinventing the wheel all the time. I needed to always freshen up my knowledge of the framework's capabilities to avoid writing some user code to solve something that the framework could do for me much more efficiently. Tutorials, short videos, and revisiting the docs will help you stay up to date with all the new things a framework can do.

Another issue that I faced was the identification of the level that a bug existed. To make that point more clear, I did not know at the first glance if the bug was happening in the client code or the underlining framework (or the way we used it). Again, deeper knowledge of the framework could position you in the frontier of handling these types of issues.

Lastly, I want to mention that there are companies that don't use any frameworks. Or at least not any all-in-one solutions like Laravel that offer a bunch of tools to help us. I found that if you look closely at the code, you can spot some set ways of doing things. There will be functions that are used in many places of the system, and patterns in place. Try to spend some time figuring them out. This will help you to avoid trying to solve everything from the ground up.

Learn from done work

As it was mentioned earlier, one of the best ways to learn (in my opinion) is by asking. Learning from others can be done by questions or by investigating retrospectively how your teammates solved some older issues.

Checking commits in the code can be a good way to find some of the problems solved previously. Another better way can be to track some tickets that someone else is working on. Find the code that fixed the ticket, and try to understand why they did what they did. Analyze the code and study the commits. This can be a quick daily practice of 15-30 minutes sessions. You can gain so much from seeing how experienced people write the code that adds value to the company!

Check general infrastructure - servers, etc

Maybe it is not one of your immediate concerns that the application is running on a single server, or it is scaling up based on the demand, but knowing where your code is run is always key. There will be times when you can't explain the current behaviour of the system by investigating the code. This is the place where you need to look at the bigger picture.

It has happened to me, to try to explain where my data was overridden after a specific call, the answer was that two instances of the application were running at the same time, one overriding the other process. The solution was simple and well-documented. Finding the problem, though, took me some time...

Tools

Master your editor

This advice can easily be considered generic, although the time spent to learn your editor and its shortcuts can be proven a great asset in your toolset. Navigating a new codebase can be daunting at first. The file structure is new, and the class names don't make a lot of sense yet. Using your shortcuts to navigate between parent classes and children or finding where the current class you are working on is used will help you save time and give you the mental space to focus on important things.

Get access to all resources available

The idea here is simple, you need to have access to all the available resources that help you carry out your daily tasks. The team you just joined will share with you some passwords and usernames for the different platforms they use. Your job is to make sure you can access these platforms and specifically the information needed in any of these. Do not let this happen last minute. When the system is down you need to have access to the logs immediately, you can't afford to search for the right password to use or get lost in the tool's navigation bar, so do these "tests" upfront and prepare yourself.

Set up the debugging tools

Any help you can get, you must get it. Learn what is the best way to debug the application you started working on. Use all the tools the team is using and consider if you can install some additional tools in your local environment. You can make the application "talk to you" when something goes wrong, and your understanding will grow at every opportunity. You will be more confident diving into a bug-hunting situation when your machine is prepared to show you in detail what is happening in your code.

It is worth mentioning here that static analysis tools for your code will certainly help you keep the quality of the code you modify high. They can also come in handy in places of the code that you need to alter to solve a bug.

Understand the automated (or manual) deployment

Usually, developers are using automated deployment as a black box. We just push our code on GitHub, and then we wait for our code to reach the production server. Maybe, is not our responsibility to make that process work, but it is very important to understand how our assets (code files, images, etc) are used by it. Be aware of any transformations that happen to your assets, and how the environment where the app runs is built.

A broader understanding of the tool will come in handy when confusing errors happen in production.

Conclusion

Being able to adjust quickly to a new codebase is a multifacet process that you need to tackle with all the possible tools you can use. A good start in your new role can set you up for success, but being always ahead of the game can be tiring. Hopefully, some of the advice in this article will help you achieve it without feeling overwhelmed.

Thinking about your overall attitude will make you a valuable member, sharpening your understanding will enable you to be a key player, and mastering your toolset will give you the ability to tackle all the issues that come your way as a professional. Be open to new challenges and enjoy the ride.

cover photo by Christina Morillo: https://www.pexels.com/photo/two-women-looking-at-the-code-at-laptop-1181263/

How to write better code with one simple realisation

Stathis Georgiou — Wed, 07 Feb 2024 20:58:12 +0000

Let's start with something obvious.

There are multiple ways to deliver the same feature. Pick a handful of developers to do the same task, you will probably get at least a couple of different implementations. Your personal style and knowledge are deciding how you write code. If there are no clear guidelines on your team, you are running free on an open field. There are shortcuts to take and pitfalls to avoid, and you decide what To do. In every line you write.

We use frameworks and agree on naming conventions so we at least have a set path of how to do things. But, there is still leeway to inject your personal choices into the code.

You choose what a function does and what is the name of it. You choose to follow the single responsibility rule or to break it based on your judgment.

Every single key you type in your keyboard while coding, is a decision made. You decide what path to follow, in every line.

Once you realise the responsibility you have on your hands, you can slow down and use it to your advantage.

Think before you type

Plan your code at a high level, Draw a simple diagram in your notepad, on the back of a napkin, or anywhere. Do it before you start typing. Write your tests, make them pass, and then rebuild your code by revisiting all the choices you made.

Push yourself to have the mindset of a reviewer. Pretend you are reading someone else's code. Rethink the names and everything else you have typed. Do they make sense?

Useful questions to ask

Is it doing what it is supposed to do?
Does it say what it does?
Can it be reused?

Avoid unconscious decisions

There is a domino effect, caused by a propagation of decisions. You do one thing and imply something else. Bear in mind, even if you leave things at "default" it also counts as a choice that has a chain reaction.

Let's imagine you create a class. The class has a series of properties, and without a lot of thinking you make them all public. Maybe just because this is what you see in all other classes of the project. The decision you just made is not affecting just the properties though. It means that your class can be used as a Data Structure and not as an Object. All the users of this class "know" all about the class, and its internal structure is exposed. That is not a bad thing, and maybe it serves the feature. But it has to be an intended quality and not by accident.

Yes, maybe a silly example but it gets the message across. You type one thing that affects something else.

Guard your code from being misused and try to understand deeply what you imply by your implementations. Pay attention to the details. Be aware of the decisions you make.

Every little helps

(for UK readers, yes I was inspired by Tesco's slogan)

We have a lot of power in our hands with these modern languages and tools we use. Freedom is endless and the world of 0s and 1s is our to shape. Accept the responsibility and embrace it.

Pay attention to everything!

Cover image by pine watt on Unsplash

Start writing better code with the concept of boundaries

Stathis Georgiou — Wed, 07 Feb 2024 16:40:32 +0000

Did you ever wonder if there is one single idea out there, that could make you a better software developer, significantly, if you understood it?

There are no shortcuts to being a better developer, but there are concepts that can help you improve your coding style once you start thinking about them.

In this article, I will attempt to approach the idea of setting boundaries in what your code can and cannot do. I will try to prove that sometimes, it is better, to think inside the box.

Boundaries are everywhere

Everything around us has boundaries. For example, in the physical world, everything occupies a certain amount of space. The laptop I am typing this article on has a "start and an end" when it is perceived as a physical object. Boundaries that are so obvious as the space occupied by a laptop are easy to identify. Everyone uses them as "tools" without even thinking about them. I can reach and pick up the laptop because I can see where it is.

Moving away from the material world, a more abstract example of boundaries can be the borders of a country. Although a physical boundary (e.g river, mountain) can form the border of a country, in most cases the borders are "political boundaries" that are drawn to a map, so we can tell, where a country "starts and ends". They are boundaries that we all agree to exist, so they exist.

Boundaries in software

Approaching closer to the idea of this article, an even more abstract example of boundaries can be found in software development. In many aspects of an application, the idea of boundaries is at least a perfect tool to explain and communicate some complicated information. For instance, the human brain cannot conceive the full image of a system's architecture if it is not broken down into pieces. Pieces that are usually represented as boxes in our diagrams describe different parts of the system. These pieces have a start and an end, too. And the importance of that is of great value.

Even more, this mental image of boxes (that are boundaries set around different parts of the system) helps you concentrate and think about what one of these boxes should do. Phrased differently, you are forced to think what is the problem that a part of the system is responsible to solve.

In the above, simple diagram, we see the 3 main components of a system represented as boxes. By looking at it we know 3 different areas are responsible for different jobs. They interact with each other but they don't mingle in any case. Perceiving our architecture as separate boxes helps us understand and build our system.

Boundaries exist organically in our systems and they happen to be the ideal tools to understand and explain complex ideas. We isolate functionalities and responsibilities in a way that the human brain can comprehend them and then work on them. Even though we encounter architecture diagrams more often, boundaries exist also in the code of our systems.

What are boundaries in code?

Abstract concepts like "boundaries in the code" are hard to explain to someone that has never encountered them being applied in the real world. Thankfully though, boundaries are everywhere in the code, and we use them every time we make even the smallest change. We just need to shift our perspective to see them.

To be more specific, every class, function and any kind of scope created by opening and closing brackets are forms of boundaries. They have a start and an end. Thinking in a bigger scope, modules implemented under a certain namespace are another form of “borders" in our code.

If we agree that boundaries appear everywhere in the code, it is obvious then, that if we learn how to use them they can be proved to be of great value. Organizing the code so every part of it is focused on a specific problem is a great start. We don't want big functions that hold a lot of functionality because they are hard to understand and change.

Setting hard boundaries on what a function can and should do is a very important idea that changed my approach to coding. As with software architecture, in code, boundaries help us understand and break down our code into clearly defined boxes.

The idea of boundaries, as used in this article, is deeply interlinked with ideas/concepts that are widely accepted as good practices for writing better software. You can find multiple resources from the great minds of programming for subjects such as “Separation of concerns”, “Single Responsibility”, "Modularity", "Don't repeat yourself" and "Decoupling". In my article, I just attempt to introduce the same ideas expanding from one common anchor point: the boundaries in our code.

Setting example code

// before I started thinking about boundaries
function manipulateAndSave($data) {
    $data['manipulated'] = true;

    $q = buildQuery("INSERT INTO users (data)
        VALUES ($data)");
    $q->run();
}

// after I started thinking about boundaries
function manipulateData($data) {
    $data['manipulated'] = true;

    return $data;
}
function insertIntoTable($data) {
    $q = buildQuery("INSERT INTO users (data)
        VALUES ($data)");
    $q->run();
}

Thinking inside the box

A function (or class) has a specified reason to exist, that is its boundary. The function has to be created with this boundary in mind and deliver only a specific functionality. Limiting the scope of responsibilities for each area of the code is the result of thinking in boundaries. The single responsibility (from S.O.L.I.D principles) principle is all about that boundary.

In addition, a function that does a specific job is easy to maintain as it is easy to "load" in your brain and analyze it, but also it is not susceptible to many changes. If a function exists only to do x with x being a very specific and isolated task (Separation of Concerns), then the function will need to be modified only and only if x needs to change!

Think inside the box when you code. A box can be the function you are working on and what it is responsible for.

Don't Repeat Yourself

Striving to create well-focused functions, that do x (some functionality confined inside proper boundaries), will make them suitable to be used again in different parts of the code when x is needed.

On the other hand, imagine a function that does x and y (y being another piece of functionality) at the same time, then it would be impossible to reuse it where x or y were needed. You have coupled together x and y so none is reusable. DRY (don't repeat yourself) is one more widely accepted principle of better coding standards that we should strive to achieve where possible. Good boundary setting helps a lot to stop repeating ourselves when we write code.

Forced to be modular

If we think in terms of boundaries, of what our code can do, we are forced to create modular code. That means our code is structured in a way that parts of it can be removed so different, suited implementations can replace them. If the parts are well-thought they can be used to "compose" the functionality we want by arranging them as needed.

Photo by Tara Winstead: https://www.pexels.com/photo/wooden-shapes-toy-6692946/

If we have a function that retrieves the data of a record from the DB, manipulates these data, and then saves them in the DB, it does too much (before refactoring). If we need to replace the existing DB technology with a different type of DB, for example, if we want to change from an SQL to a Document storage, that function will need to be altered.

In addition, if we need to change the logic that manipulates that data the same function is again to be altered, and possibly affect how we save data in the DB. These extended boundaries, of this function, contain both manipulation and persistence code making one coupled with the other. Any change to one of them is possible to break the other one.

Alternatively, if we split the logic into two separate functions (after refactoring) (Separation of concerns), it would be much easier and safer to remove the function that retrieves the data from the SQL storage with one that retrieves the data from the Document storage. This change would still require the part of data retrieval to be rewritten, but it would be confined to the boundaries of the corresponding function. The rest of the code will be unaware of the difference that was made.

One more benefit of modularity is that the interfaces between modules become part of our design, forcing us to consider how different parts of the system will interact with our code. This is one more game-changing idea for me, as most of the systems I have worked on don't respect the boundaries so much resulting in blobs of data being passed around crossing all kinds of boundaries (leaky abstraction) and causing unpredicted behavior and uncertainty in the code.

Easy to move toward the unknown

Designing your code in small isolated parts that deliver specific functionality, enables you to start coding them before you have all your solution figured out. This improvement makes you much more agile in tackling software engineering in general. You build what you know, test it, and deliver it without caring about other dependencies. Blockers can be eliminated by replacing unknown parts with “dummy” implementations that will be replaced later when the knowledge needed is gathered.

Going back to the example of the two functions above, there are multiple scenarios in which you could be blocked if you wanted to deliver the whole big function at once. Imagine if you did not know yet what type of storage you would use (this can even be a decision of another team), would you cross your arms and wait for that decision to be made or start working on what you know? I vote for the latter, you can define your function’s boundaries as the “function that holds the manipulation logic” and implement it. You can even go one step further and create a dummy function that “fake” saves data in a DB so you can define the communication between these two functions too!

The ability to start writing code before you find out all the unknown is crucial, enabling the developers to experiment and get feedback, on their code, as early as they can.

Staying focused on one thing at a time

Thinking “in" boundaries will increase your focus and guide it on the individual task. Knowing that the function you are creating is responsible for solving one and only one problem will force all your attention to be directed toward that one problem.

In the past years, the idea above was one of the biggest differences I have seen between experienced developers and the rest of us. It was eye-opening to watch and compare the commits from different developers. The more "junior" commits would have code changes scattered in different functions and classes, whilst the senior commits were small functions that delivered small pieces of functionality.

It is liberating to be able to focus on one part of the code without thinking about all the rest but it is important to always think about how this part will interact with everything else.

Boundaries create testable code

One popular and widely used type of testing is Unit testing. With unit tests, we aim to test a “unit” of our code, which can be a class or a function. If our functions are defined by well-thought boundaries then they are easy to test, because specific functionalities are isolated and can be tested in a vacuum.

On the other hand, highly coupled code is hard to break down into smaller pieces and test if they work as expected. Simply put, a function that is doing too much, cannot be broken down into individual pieces that are testable.

In our example function, before the refactoring, the function was the manipulation of the data and was also responsible for saving them in the DB. If we wanted to test the manipulation logic was impossible without testing the persistence logic too. The test will not return specific feedback for a “unit” of our code, rather it will return feedback for “all” the process, leaving us not knowing what went wrong.

After refactoring, the code that manipulates the data is separated and easy to be tested alone. We can check if the manipulation algorithm does what is expected and get feedback only for it. In addition, the persistence logic can now be tested and validated as a different unit of our code.

Conclusion

Having well-defined boundaries in your code can help you write better software. As with everything in our profession, it will require practice to start getting the benefits of that idea.

This article is just an attempt to scratch the surface of bigger concepts from a unified perspective. But hopefully, it will show you that this idea is worth your attention. Check more resources that are related to the concepts mentioned above to have a deeper understanding of what boundaries are all about.

And never stop learning!

cover photo by Alexey Demidov: https://www.pexels.com/photo/red-and-white-stop-sign-10058530/