Career

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.

​Read More
Career

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.

​Read More
Career

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.

​Read More
Career

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 [amazon_textlink asin=’0137081073′ text=’Clean Coder’ template=’ProductLink’ store=’housefrommars-20′ marketplace=’US’ link_id=’eddd728d-83ed-11e7-986f-a9b48d16ce7c’] 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!

​Read More
Career

Why we fail to finish side projects?

I can’t think about single developer who hasn’t tried or thought about starting a side project. But most of those side projects are never finished. Most of them are never even started. So what is the problem?

​Read More