Value Object vs Entity

What is Value Object, what is Entity and why should we care? Let’s take two examples, Currency and Person.

But before we start, let me give you an answer right away. Currency is value object and Person is entity.

Why?

Currency is something that has clear value that does not change easily. For example, Dollar is a currency and his ISO code is USD. It’s always going to be USD and that’s not changing any time soon. When we initiate the new dollar we want to be able to reuse that object all the time from now on in our application, because they should all be the same. We don’t distinguish between each dollar.

On the other hand each person is unique. When we create a new Person object, we have distinguishable properties like, name, age, birth day, picture, etc…

This is the first characteristic of recognizing what should be Value Object and what should be Entity. Value object is object that can be kept immutable.

Next, the object is value object if it’s conceptualy composing related attributes as an integral unit. Since this is a bit complicated definition let’s take an example and continue with currency. Let’s say we have a bank transaction. Each bank transaction has it’s currency.  Transaction is clearly an entity because each transaction is unique with unique id. We can make currency just one more attribute of transaction like this:

We can do this and it would be perfectly OK solution. The problem that we have here is that we will need to validate currency. If we know that objects should be responsible for validating itself, does it feel OK to You to have Transaction object be responsible for validating ISO code of currency? I didn’t think so. Btw, in this example amount should be extracted to a value object – Money. If we do that, Currency should not even be connected to transaction at all. Let’s see concrete example of this:

Value objects do behave as basic types in may cases but not in all. If you would do this you would get results that are not the same as if you would use basic types instead.

To avoid this we can just implement a simple equals method that would check if ISO code is equal.

One of the most important characteristic of value object, as we already said, is immutability. The question is how to achieve this?

I will try to explain again with an example. We have money value object with dollar currency and we want to add some money on top of it. We create new money value object with amount we want to add and currency. What would happen if that currency is euro. The request should fail.

This way we can be sure that immutability will be guaranteed. Each time two instances of Money are added, new instance of Money is returned. It will always be free of side-effects which is also one of the most important characteristic of value objects.

When testing value objects we need to take care that we also test immutability and side-effects free behavior. Let’s test our add method in Money class.

Using value object is highly recommended as it helps you plan conceptually your application. It’s important part of Domain Driven Design.

If you have questions, leave a comment or hit me up on twitter @housefrommars

Don’t write good comments, write good code

When a new programmer comes to our team, one of the first questions we are being asked by her or him is how come we have no comments in our code. So we have to tell the same story all over again. If I am personally asked I would give the answer that if you had to comment a function or class, that meant that you had given up on its quality, accepted defeat and then have to use English to describe functionality instead of writing clean and clear code.

Header comments

It is not only the issue about the method or class description comments. I come across a lot of “header comments” as the ones that follow:

Every single line here is unnecessary. The information like author and date created is information that we have in our source control. We do not care who created the file ( which we also can see in VSC ) when we can see who wrote each and single line with git blame ( praise ). Phone and e-mail are redundant because what could you do with e- mail and phone of author. You could call them and say their code is bad!? Also I do not care about your personal comments, such as the way you felt when you created some piece of code, whether you were angry or sad if method turned out the way it did or something similar.

I did personal comments in code all the time before. It was my way of therapy. At the time, I thought I needed to unwind in that way because project I was working on contained a lot of bad codes and I gave my contribution to that by writing more bad codes and I was writing personal comments by which I was justifying myself in my own perspective.

I would write comments like these:

I am aware of the fact that I behaved like an idiot. Comments like those do not give any value to the code. Instead of hating my life, I should probably try and fix that part of code that was responsible for my feelings.

Point is not to do this. No-one cares. Do not complain, especially in your code comments. Instead, do something about it and fix it. Those kinds of comments really makes you unprofessional in the eyes of other experienced developers. You do not want that.

Description comments

Description comments are very common. I think (looking at just programming side of things) they are even worse than personal comments. As I said before, when developer needs to use English to describe behavior of code, that means that he had given up on using computer language to do the same. Less experienced developers often do this. They rely on comments to express behavior of source code, instead of using actual code.

There is simple and easy rule you can follow to fix this. If you feel that you need to write comment to describe something, then stop, look at the code and refactor. Refactor until you do not have the need to write a comment anymore. Simple enough.

There is argument for comments. They should be present as a way of documentation of what code suppose to do. Wrong! We do not care what code is supposed to do. We only care what code is actually doing.

There is an argument that comments should be present to explain to future programmer why the old one created that particular function and what his thought process was. Even though this can be controversial, I do not agree that this is necessary. It can sometimes even be counterproductive. Again his thought process should be clear from the code he wrote or at least we can see his source control history. Also to write good comments, you have to be a good writer. It is really not that easy to effectively communicate with your colleagues through comments.

There is an issue that writing and maintaining code is also very expensive. Now you have to worry about changing not only code, but comments as well. Each time you write some new code or have some new idea you have to update the comments. Yeah, that is not going to happen. You will forget eventually to update comment and then you will have misleading description.

This is why I think thought process comments are something you should also avoid.

Docs comments

The only comments I think you should write ( yes, there are good comments ) are not really comments at all in practice, but technically they do belong in this category. I am talking about documentation comments.

There is nothing wrong with this, especially if you are using language that is not strictly typed, these things help you keep parameters types as well as return types correct.

If your feel your code is too complex to understand without comments, your code is probably just bad
24 Jul 2008 – Coding Horror

What do you think? Do you write comments in your code and why? You can leave a comment here, which is not as bad as leaving comments in code.

Practice is only thing that matters

Software development is not the God given talent. Yes, it is true that some people are genetically prepositioned to be better in that area, just the same as Math, Science, learning languages or fixing cars. But that will give you only small percentage of advantage over the less talented. You will not become a professional in that field unless you practice and learn, and you will not become proficient if you do not learn and practice every single day.

Practicing every single day does not mean that you will have to work at home after your day job. The work you are doing on your day job will be sufficient, but choose work that will challenge you every single day. Do not settle for every day routine. Make a note that you should learn new stuff every day. Just one thing, every day. It can be a new method from some language you are using, new bash command, new shortcut on your IDE, etc,.. It could be anything related to your profession really.

What most of programmers, or all people really do, is when things get hard, they give up. When I said previously that you should take work that would challenge you, it meant if stuff you were not learning or doing did not seem hard to you, then you were not pushing yourself enough.

The best results you get are when it becomes really hard. When you are annoyed and cursing at a problem and at yourself for not understanding something, that just means that it is perfect time to push more.

When you are running and when you feel like you cannot run any more, not even 5 meters more, that meant that you should push for more, try to run at least 10, because the reward will be sweet.

Trust the process

People usually get stuck on solving hard problems or they do not have nerves to finish learning of some new thing because they are focused to the final result. Instead, we should focus on a process.
For example, there are some children books that learn them how to draw certain objects. The process of learning is divided into steps.

For the first step, child is only required to draw a square. That is it. Then next step would be learning to draw a roof by only drawing a triangle. Third step is to mix previous steps, so now we have a square and a triangle that already have a premise of a house, and so on. So children can get frustrated when trying to draw a house if they start drawing the finished house, but if they go through the entire process, before they even realize it, they will draw a finished project, by following the certain steps.

Same thing is with learning the letters. Children learn to write letter by writing it multiple times, just repeating and repeating the letter “A” for example. Writing it 100 times in a learning book. The same thing is with advanced concepts in programming. We will learn them if we try and use them practically and repeat that as many times as possible. It seems that learning to write and learning advanced computer science concepts are not the same, but writing for little child is as difficult if not even more, as it is for us learning advanced programming concepts.

Code Kata

In my experience, programming is sometimes looked up as some different profession from the others. What that means is that we often think that different rules apply to us, then to other professionals who work in finance, or layers. They learned their work by repeating stuff. We think that we should not repeat ourselves. And that is mostly true, because we are going to repeat something then we should automate it, but we should only automate stuff that we know really well. Let us take an example. I want to create a new project in Laravel and setup the database credentials, generate secure key, run migrations and seed the database and maybe do some more custom stuff that I always do when I am creating a new project. Of course I want to automate that into one command, but first I want to repeat this process several times manually and get all the commands stuck in my brain, so that when I am on other computer on other environment I can still do these things without my custom all-in-one command.

Programmers tend to copy code they find on Stackoverflow or some other blogs, not even read it and forget about it afterwards, which is the worst thing you can do. You should take the code repeat it by hand several times and then you can make a script. That process of repeating code or commands is called “Code Kata” named after Karate exercises you learn and repeat.

Stop when you’re done

Les Brown, famous motivational speaker said that “You should not stop when you are tired, you should stop when you are done”. This saying is not something you should take literally, because I am a big advocate for rest when you get tired like I wrote in my previous post, Work ’till you drop dead, but it just means that sometimes our brains wants us to think we are tired, when actually we are not there yet and we can get the job done in that session.

Even though it became a cliché I must say that “Life is not easy”, everything you do that you are not feeling comfortable with will be hard, but if people did not get out of their comfort zone, world we know today would not exist, maybe fire and wheel would not be discovered and you and I would not even exist. So keep pushing and since it is beginning of a new year, let this be one of your New Year Resolutions.

Pre-commit hook for behat tests

If you are working on small project and you’re using Behat tests, there will be times when you change code and as consequence of that, introduce a bug or break a feature. And more often than that, because we are humans and we forget to do things all the time, you will not run your functional ( in my case Behat ) tests, so bug will go live.

So in order to automate that i created a pre-commit hook that runs Behat test and then rejects commit if they fail.

Git hooks are located in your .git directory and you can have your own bash code executed on every git event you choose, pre or post event.

Feel free to play with this little script and improve it as it pleases your needs.

P.S. If you want to skip this check then you can commit your code with

 

Work ’till you drop dead

I always listen to the story that person cannot become an excellent developer if he/she only work at his/ her job and do not do any side-projects or read at ones free time at home. So let us analyze if that is correct.

The argument is that in order to become great software developer it is not enough to just do your daily job. You should also write applications in other languages and contribute to open-source projects as well.

This is not a dilemma if you should do side-projects or contribute to open-source. Please do. I encourage you. The question would be if this make you better developer? Sure you are going to get more experience which you can use later on, or maybe you will learn a new language, but we have one crucial thing that you should be careful about.

Stamina

You productivity will get worse with each day that you spend working more than eight hours. Eventually, that will lead to a burnout and you do not want to be in that kind of state.

Tony Schwartz wrote a nice blog post called For Real Productivity Less is Truly More in which he mentions sleep researcher Nathaniel Kleitman study which deals with humans after working at high intensity for more than 90 minutes begin to lose focus, feel hunger and are in desperate need of break time.

So in order to be able to use those skills you can acquire during that side-project, you need to be careful and take a rest.

Another argument against this is that most of the people who think that we should work after the period of work from nine to five , have awful and unsatisfying jobs. As we mentioned before, working more in your spare time can be bad for that day-job because you will lose focus and be tired all the time, so you will not be able to do your primary job as good as you would like to.

Second thing is that if you have bad job, do something about it. Change the culture, change the process, change the code, make it more challenging, introduce new technology, create something out of nothing if you must.

If you try everything and you have obstacles that you simply cannot overcome, than change the job. Life is too short to be spent on lousy jobs.

What if you have to work more on your day-job. That is also the situation a lot of developers are finding themselves in.

Overtime

There are two types of overtime, the paid one and unpaid one.

First one is rare, because since it is payed and it is usually paid more than regular hours, companies try to avoid it if possible. But even if it is payed you should be very careful. Sometimes free time is worth more than money.

Second one represent free hours you are giving to your company.

Imagine if your boss comes to you on Friday and tells you that you really need this new feature until Monday or you will lose big client.

You will probably help out. And you should. Especially if that is one-time thing, whole team should come together and save that client. Also if you were working on a project for couple of months, and especially if you were lead developer or team lead, you would want to work more hours when time comes for a big release just so you can make sure everything works. It is an obligation you have, not just towards your employer but to the project and code itself.

Problems start when this becomes a norm, when it is expected of you to work every day two or three hours more, when you have working weekends and so on. If there are often emergencies and if often you need to put off fires, then you have to set up some boundaries. Either you get paid for overtime hours ( remember to be careful about this ) or just refuse to stay.

Estimates

There is also one more angle to this story in which developers are to blame entirely and these ares unrealistic estimates. When we estimate that some feature is going to take five days, and it turns out not to be that easy, than we tend to work crazy hour to deliver on an estimate that we gave.

Always estimate conservatively and double the days you think you can solve the issue. That can have double positive impact, first on customer if you end up finishing before deadline and secondly you will not have to work overtime if the unpredicted things happen.

What is your story? Did you have to work crazy hour? Does doing side-projects help you on your day-job or not? I would love to hear your opinions, so please leave a comment.

Architectural Styles Explained in PHP

You can decide on many architectural approaches and styles when starting new PHP application. This will be very superficial overview of different architectures, but it will be enough for you to start thinking about different ways you can structure your application. I picked four to talk about. Three will be in this post and the last one “Command Query Responsibility Segregation” deserves its own post.

One of those four you should never use, let us try and guess which one.

Good Ol’ Days

Yes. You guest it. The good old days architecture is that one that should not be used. Nevertheless it should be mentioned here. This is the old way of writing PHP application. People often call this approach as PHP 4 way of coding. That’s too generous. Because this type of coding is more of PHP 3 style.

You see back then, there were no classes in PHP and separation of concerns were alien concepts among the PHP community.

Let’s see one example of application written this way.

As you can see html and logic is mixed together. We call this “Big Ball Of Mud“.
These days, there are still applications that use this style of coding. One major problem here is also that this uses mysql_real_escape_string to escape parameters, which is proven to be unsafe, so the risk of sql injection is high.

Application like this is the main reason why so many communities look down on PHP and even this is now history. Some developers still use this style of programming when beginning their new projects, which is directly hurting PHP community.

Let’s talk about some newer architecture.

Layered Architecture

This was major improvement because it introduced separation of concerns. As a consequence code became reusable and maintainable.

Rule for layered architecture is that each layer must be tightly coupled with the layers beneath it. What layered architecture tries to solve is problem of mixing different components of an application. To go back to our previous example, blog post view representation should be completely independent of blog post as conceptual entity.

The reason this is good is that blog post as an entity can be visually represented by one or more views, as opposed to being tightly coupled to a specific representation.

We know this type of architecture by more famous title ‘Model-View-Controller Pattern’.

Model manages data and logic for business rules.

Controller job is to organize interactions between other layer and trigger actions on model depending on user inputs and send messages to view in order to refresh the representation.

View has a responsibility to provide visual representation of model and provide a way to trigger changes on Model state.

So now let’s take a look at simple code example extending on our previous code snippet, for this architecture.

Model is now represented by Post and PostRepository. But we have another Post representation. It’s Post service.

Services are when the real magic happens. Its job is to orchestrate the behavior of Post.

As you can see Application services are the ones that make things happen.

View is presented by some of the template languages. The most popular are Twig, Blade, etc… You can represent it by plain php and html. Recommended way is to use some of the languages for that, but it is not vital.

There are some risks when applying this architecture. You can see that in PostRepository we are directly placing infrastructural details. That is violating Separation of Concerns. How to fix that?

Hexagonal Architecture

Hexagonal Architecture (Ports and Adapters) was defined by Alistar Cockburn in his book Hexagonal Architecture. It depicts application as a hexagon, where each side represents a port one or more adapters. Port is a connector with a pluggable adapter that transforms an outside input to something the inside application can understand, and vice-versa. It can also emit message and transform to whatever outside can understand.

[video_page_section type=”youtube” position=”default” image=”https://housefrommars.com/wp-content/uploads/2017/10/hexagonal.png” btn=”light” heading=”” subheading=”” cta=”” video_width=”1080″ hide_related=”false” hide_logo=”false” hide_controls=”false” hide_title=”false” hide_fullscreen=”false”]https://www.youtube.com/watch?v=K1EJBmwg9EQ[/video_page_section]

This all sounds complicated but let us apply it to our example from before and solve infrastructural details being placed in our model directly and make it more clear that way.

In order to retrieve blog posts from the database, we need a Port in this case that is going to be PostRepository. Remember this is Port because we will need to communicate with outside, in this case it is database.

This interface exposes Port that the application will retrieve information about blog posts through. Now we need adapter for this.

Now our PostService looks like this.

You can see now that we can easily change database without the need to change our model domain. If we decide, we can create RedisPostRepository and just replace it, if we decide to.

This post is being heavily influenced by Domain Driven Design in PHP which is awesome book. You should definitely check it out here.

Five basic things developers do wrong when building API

First thing that is important, when making API and what developers often forget, is versioning.

Why is versioning important?

Well, let’s consider this: You have built your application around some API and of course now you are heavily depend on it. Consider that you have your methods that fetches some JSON from path that you have as constant in your code, and other methods that parse that JSON the way you need it. So, what happens when API developers decide that they will change everything and make new version of their API.

If they did their job right, you wouldn’t notice anything. Why? Because they will not change a single thing on version of API you are using.

Let’s say you are fetching some API data from this url:

If they changed anything they don’t mess with this path, but instead make a new version and push breaking changes there. Now url will look something like this:

This way you can still use old API version and you get to decide when to switch to the newer one, only when you make all required changes, so that your application continue to work normally. Always have API versioning included. Even though this is basic thing, I come across APIs that do not have it, on regular basis. Do not do the same mistakes as they did.

API Documentation

This is something that I know a lot of developers do not want to do, but it is part of their job. By not having good documentation, you are undermining all good code you wrote, because no one is going to know how to use your API.

Write documentation with the goal of not get any support tickets or emails. If you ever get ticket or email with some questions that means that you are missing some documentation part and that you should immediately update it and add whatever your customer has just asked you to. Yes, even if that question is something stupid (of course there are stupid questions ). If some question doesn’t belong to any category of your documentation and you do not know in which section to put it, just have FAQ section in your document in which you can put all inputs you get from clients and customers.

Also, by having good documentation you are seen as very competent and professional, and your service that you provide will be more successful and trustworthy.

HTTP Status Codes

This one is a bit controversial, but let us get it out there.

It is wrong to return HTTP Status Code 200 (OK) with error message as a response. HTTP Status codes tell application how to react to request. So if we return code that says that everything went OK, even if we have just had an error, it means that we are not using HTTP the way it is intended to be used.

I know that some of you will say that HTTP status codes have nothing to do with business logic of API and technically request is OK, there were no errors on server or request was not bad. Nevertheless, you should know that HTTP is an application protocol, and HTTP status codes should reflect that. Also this by not using HTTP code as they are intended to be used, you are breaking REST, as 2xx is considered to contain response that have that resource as return object. So if we are not getting resource back and instead we are getting error response, you cannot have 2xx HTTP status code.

Testing Environment

Consider you are doing an integration of your service with some API. Let us say that it is payment system. Therefore you would have to test everything twice before releasing it to the production, because we are dealing with people’s money, so we want to be double sure everything works as intended. There is a big list of all the things that can go wrong, but you have no way to testing that.

Let’s say this there are 4 scenarios for payment result:

  • Payment can be successful
  • Payment can be refused ( for different reasons each of which have unique code and message )
  • Request is bad ( unsupported currency, invalid amount, etc…)
  • Fraud detected on Credit Card

We can test three out of this four scenarios. Our API provider did not prepare fraud detection scenario. We can never get that error message, response is different and different parsing and actions need to be done. Because of this reason, we now have untested integration.

So when you are building an API, always consider to be client friendly and implement test service that will cover all possible scenarios.

In our example that would be simply solvable by having dedicated number of a test card, so we client sends the request for payment with that card, it would respond with fraud detection error.

Consistency

By consistency I mean two things.

First thing is not to mix return types for different API endpoints. I had “pleasure” of integrating system that had authorization using SOAP and the rest was done in JSON. Why would you do that? Would you want somebody to do that to you? No? Then do not do that. Be consistent. It is not a problem to have entire service in SOAP, just have everything in that one.

Second thing you should be consistent is to use property names consistently. Do not have property name api_key (underscore) in one endpoint and apiKey (camel case) in another. Just the other day we had one API use property merchantPassword in one request and then merchantPass in another. That sort of thing just shows that you are being lazy, inconsistent and unprofessional.

Do not be stupid on small things like consistency and lose your reputation as good API provider.

If you disagree with me or have something to add please leave a comment and I will try to respond to anyone that is in the mood to talk.

Also I am writing a book about Legacy Projects so if you want to check that out click here.

Preparing for your first job

It’s your first day at your new job. You are hired as a software developer. You get read and write permissions for the project you are going to work on. You start reading the code and as you go deeper and deeper into it, you start getting a panic attack. This is not what the college or your working alone on some project from scratch prepared you for.

First thing that you have to realize is that you are not alone. Every single programmer felt that way. We even have the word that describes that particular thing.

Impostor Syndrome

Impostor Syndrome is fear of being exposed as a fraud. While you are looking at that code, all through that process, somehow the feeling that you have tricked you employee into hiring you, gets bigger and bigger. Best way to fight that feeling, is to expose yourself. You have to ask questions.

Asking Questions

This is where a lot of us get this part wrong. We go into two different extremes. Some of us do not ask questions at all. This is wrong for apparent reasons. If you are new to some code or project, it is perfectly normal to ask questions. That is something which is even expected from you. By not asking questions, you are just feeding that impostor fear, and you feel all alone in that sensation. Not to ask questions will be bad not only from coding aspect, but psychologically also. Asking questions is pivotal in establishing yourself in the team and eventually adding value.

On the other hand, we have developers who ask too many questions. Yes, you can ask too many questions, regardless of people telling you otherwise. You will be respected more if you do some investigation first on your own, and try different solutions to your problems, and if that fails, come back with questions. You look like a competent developer if you phrase your questions like this:

I am having problem with getting a and b. I’ve tried using c and d, but that only produced e. Can you help me?

Person you are asking will be more engaged when you phrase your question like that and when solution is not something obvious that you should check first.

Legacy Project

Let’s get back to that code you were reading. You have to realize that applications that are out there, powering our 21. Century world that we know are mostly written badly. The most of them are legacy projects, they are maintained by expert beginners and the most of them have serious security problems as well.

If you are in the company that has a lot of expert beginners, you have to fight not to become one of them. This can be very challenging because, expert beginners are mostly presented as superstars in certain company and you are a newcomer. So what chance do you have against them?

This is very tough position to be in. But there is a way. You have to prove with value that your way of thinking is worth more then theirs. By value I mean results that could be easily seen.

Adding Value

Most of companies that are stagnating have applications that are full of bugs. Why? Well one of the reasons is that they are inventing a wheel. For example, lets say they have their own ORM in place, so instead of using Doctrine or Hibernate, they use their own implementation and because of that they have issues. Your value there could be to suggest a change, and not only that, but to show them, on smaller scale (not by overwriting entire project) how using this well established library will help them not to have so many bugs in production.

Second important thing is to get your colleagues on your side. You cannot do all that work if you are alone. Acting together as a team in improving some procedures that you all have problems with is essential in changing culture of company.

Small dot in space

There is a middle line here also. There are companies that are running normally and by that I mean that projects are doing fine. It is nothing exciting but it is working. Some projects have more and some of them less lines covered with tests. Bugs in production are rare. They occasionally happen, but not very often.

Working in company like that can feel that you are there as just one of the wheels and can’t really make a huge difference. To fight that, you have to be very proactive. You have to constantly come up with ways of improving code or process, but you have to be careful that solutions that you provide, really work.

Hectic Environment

Finally we have startup companies. This has two sides of the medal. One of the best part in working in startup is that you get to learn a tone of stuff and from different ranges also, and you get to learn all that pretty fast. The reason for that is that you have to learn fast. Startups are all about next release. Every single next release will be release that make investors millions. We all know that is bullshit, but that is how startups get their energy. Other side of the medal is that mental health can deteriorate quickly. Amount of stress in this situations is very high. That is why you have to be very careful and think about your health first.

Code written in this hectic environment can be very bad. Hackathon bad. Try your hardest to resist that. Resist to write bad code! Don’t be lazy! That deadline that you are given is never that strict. I am speaking from my experience. It will be worth more to the company that code is well struct and tested, then to have pushed it on time.

Real World

Real world programming is not like you see it on tutorials, where projects are written from scratch. You will be thrown into project that is already in production and making money or in best case scenario project that is not yet released but big chunks of code have already been written. Odds are that code will be bad. You will not use cutting edge technology, so don’t expect to rewrite some old PHP code to Go and I hope you are not thinking that you will change MySQL to MongoDB (do not do that even if you have opportunity). That’s expensive. Software that is working is rarely touched just for code improvements sake.

Even though, I am not big advocate for a code rewrite, and I would never recommend it, changing code just for code improvements is something you should try doing but in smaller incremental steps and that is essential into making your code better. I will be talking a lot about that in my eBook Living With Legacy Code and if you want to find out more information about the book and even get it for free just subscribe to my list and find out more.

Long-term caching with Webpack

I am going to show you simple way to cache public files. Using this configuration bellow, we are instructing our server and browser to cache the file for as long as possible.

Being a professional programmer

In this article I will tell you about my story of becoming the professional programmer. I have been programmer for 9 years now. For the most of that period I was not the professional one. Not that I did not work in companies for money (which could be the definition of being professional in some way), but I was not acting like one.

What is a professional?

Being professional is when someone has aims and qualities that characterize his profession. In software/web development the main aim should be to produce good products and quality in this case represents being able to use best practices to do so.

Why did I not do that?

My aim, at the beginning, was always to satisfy my bosses, which meant to produce products that only appear to have quality. The main reason for that was that the features had to be pushed in production “yesterday”. However, underneath the surface, code that was powering the product was not maintainable at all. As a result, bugs in production were a common thing.

As you can tell, not only that my aim was wrong, my qualities were also a big problem. The reason for that was that I have just started my career and I did not know the better way to deal with this issue. I thought that was the way that all companies and teams were working accordingly. Sales department comes with a big new client that would be the next big step for the company, only if we could push this set of features in 7 days. Working on weekends and after-hour were a common thing and we would all gladly do it.

Startup Culture

That was 9 years ago. What saddens me is that this “Startup Culture” is a new standard for all new companies that are trying to push their new products to public. The more experienced developers that I was back then are doing the same mistakes I did. It is expected of you to do what I have just described. Eventually, we came to the point of this post. If this is the standard now, then how could we be the professionals.

Honestly speaking, it is very hard. It is impossible to push features with this tempo and write meaningful code.

Being professional means that sometimes you should stand up and fight. Communication here is the key. You need to communicate about all the problems, with this approach, with your bosses and product owners. In doing so, the person could expect one of two possible outcomes. The first one could be that they listen to you and agree to work on a problem together, because you are playing for the same team at the end. The second outcome could be that they could dismiss you and sometimes even fire you if you keep consistently raise that question to them.

If latter is the case, that could very well be blessing in disguise. By that I mean, who really wants to work for company like that. Right?

Financial Stability

Well, let us go back to my beginnings again. At that period I was working at the only company that would hire me at that time. And the pay was good. So, yeah, I, nine years ago, would want to work at that company. We need to be honest that financial security is a big motivator.

Being ethical

Being ethical is another quality real professional should have. If company had been doing something that you thought was wrong  and not only in development practices, but also in other areas, like deliberately coning its customers, no matter how good the pay had been, right and professional thing to do would have been to quit if you could not have changed that.

And just like writing code that is bad and not maintainable, writing a product that will do harm to your customers on purpose is not what a real professional would do. Is that something that you really wanted to continue doing on daily basis?

Bill Sourour talks about this in his famous blog post The code I’m still ashamed of. If you didn’t read it by now, you definitely should.

We are the part of the problem

The company problems are not always an issue. Programmers themselves are also the problem. A lot of times in my career I felt too lazy to do the right things even if I had time and could easily do it. Result of that was the same as above. Uncle Bob talks about this in his book a lot. You have to have pride of code you write. If you do not have pride, then you are not doing it right.

If you submit a program to a QA team, and they get back to you with 20 bugs, that means you did lazy, half-arse work. I am not talking about misinterpreting features given by the product owners or project managers here, I am talking about plain bugs. I was in this situation more then once. If you continuously do this, ask yourself what is the problem!? Why don’t you have motivation to do better job? Is the project boring? Is the job boring?

Something is definitely wrong. No matter how bad the development process is, this amount of bugs means that developers are not doing their job as they should.

Taking responsibility for a bug is also a part of being professional. But think how silly you would look if you would continuously took responsibility for those 20 bugs each time you submit an app to QA team for evaluation.

If you practice a peer-review system, submitting a code that is bad and untested will lower your reputation within your colleagues. Do you want that?

Conclusion

So next time you write a code that is eventually going to production, think hard, is it worth it, not to give 100%? Is it worth it to create a code that you are not proud of?

Programming is a profession like any other. Would you have courage to cross the bridge that was made by architect or engineer who did not put 100% of themselves when she/ he had designed it? A bridge that she/he was not proud of ? I think not.

I changed my ways, I encourage You to do the same!