08 - conferences2

“I don’t know, should I go?” is the question often asked by new coders. And the not so new ones, I’m afraid.

“I don’t feel like it…”

“The talks won’t be what I would like them to be…”

I’m not saying you will be doomed if you are among the people saying these stuff, but your professional life will hugely benefit if you decide to go. Please don’t be that person which doesn’t feel like doing something useful for themselves.

Don’t concentrate on the talks if you don’t want to – it’s networking you should pursue. It doesn’t matter if there will be 3,000 or 30 people. You will meet someone new from your field, you will hear something different from what you hear every day. Who knows, you might start a new project with people you just met or you will be offered a job in case you are looking for one. Take a look at the picture above this text. I wasn’t looking for a new job on last month’s WebCamp, but still these pamphlets managed to find their way into my goody bag (on an unrelated topic, I do love goody bags).

“I don’t know enough coding to attend a conference.” You will never be 100 % ready for anything in this profession. The sooner you realise that and relax a bit, the sooner you will see real progress. If you come to a conference, people won’t ask you if you’re super-advanced or a newb. Your attendance means that you are willing to participate in the activities your community organises and that you might actually be a team player. Being an exceptional engineer with absolutely no social touch won’t get you very far. I know such engineers.

“I have no one to go with.” – even better! Head out to meetup.com and find a group near you which covers the conference field. Send an email asking them to join if anyone is going. Or, if there’s time, attend a meet up before the conference and make some acquaintances there whom you can go with. That way you’ll already be doing a lot of networking before the conference even started. I know it’s not always comfortable to approach strange new people because it’s uncomfortable for me, as well. But, the further away from your comfort zone, the greater the benefit.

I heard this CEO talking on one of such meet ups, he was looking for new people for the company. I asked him if he has a job ad posted. “No”, he said, “first I like to see if there are some people interested on meet ups. If there’s no one, I ask them if they know anybody they’d recommend. Job ads are my last resort.” If that doesn’t sound as a convincing argument to socialise, I don’t know what would.

Hope to see you there.

 

Read more

fun

So far, I have been writing about some of my experiences regarding learning to code, working as a coder who is just starting out etc. and I didn’t mention a very important aspect of the whole story, and that is fun.

It’s quite simple, actually. If you don’t like what you’re doing, chances are it’s going to be a lot harder for you to learn it. Sure, you won’t always get fun tasks at work, but when you are learning and practicing, you should always chose a task that has some appeal to you.

Let’s say you are learning loops. You need to learn them and be able to recognise a problem that requires using a loop. Those problems are countless, so start with the ones you like. Remember those punishments in school where you needed to write “I will behave during class” a hundred times on the blackboard? Well, you can do that in a loop in a fraction of a second. Want to calculate your annual salary using just addition, without multiplication? No problem, loops will help you. Remember – you can make many mistakes in the meantime! Everyone makes mistakes while writing code. It’s not etched in stone, the code can be easily changed in your text editor and you can run it again.

I remember an anecdote from my wife’s college days. She attended a class in sociology (I don’t remember which one exactly) and at the very beginning, the teacher asked the students to tell him what would they like to be doing at that very moment. “I’d like to be on the beach”, one of them said. The teacher wrote it on the black board. “I’d like to be at home, snuggled under my blanket and watching movies”, the other said. “I’d like to be exploring space”, my wife said.

After hearing and writing down multiple examples, the teacher told them: “Take a look at the blackboard. None of you said they would like to be working. All of you opted for fun activities. Marx was wrong, humans are not naturally beings of labour.”

More and more companies and recruiters seeking new people know this and they approach candidates differently. They tell you you’ll be working on cool projects in a friendly atmosphere and that you’ll have beers on Friday. They want you to know fun is part of the job description. I like that (as long as other job perks at the same level). They know that a worker who likes his workplace and colleagues will be better at his job and that he’s more likely to stay.

Don’t get me wrong, it’s not all fun and games. Sometimes you’ll be on the verge of quitting, frustrated and disappointed. That is normal and it will pass. Try to have as much fun as you can while learning to code and you should be fine. If you cannot see any fun in it what so ever, it’s not the end of the world. Perhaps you just hate the whole thing and don’t want to do be a coder. There are a thousand other things in the world you can be. But try giving coding a chance and have fun while doing it.

Read more

choose

No one will have a larger impact on your career trajectory than your boss. And not just that, he/she could influence your confidence, motivation and persistence more than you know. It is essential to take into account more than just the job itself and the package that goes with it when considering taking your first position. Or a new one.

Yes, the company name might be a big one. You get a brand new laptop and a decent salary. Free cereals, fruit and other nonsense every morning. It’s all good and it will help you, but trust me, that is not all that matters. If your advancement and well being is not a priority for you boss, you will not go far, despite the free gym and sauna. Perhaps the best thing to do here is to explain through two examples. I could easily write more examples similar to the Story nr. 1, but you’ll get the point.

 

Story nr. 1 – You look too happy

This is a weird one. Before my current position, I worked at a large company, building a large enterprise app. Boring as hell, but I was in a good team with a good team leader. However, my team leader was not my boss. We had at least three bosses that I know of, one of them being in the same large room with us. One boss pushed the other and so on until the pressure was finally directed to us, the coders.

To be honest, my team didn’t get that much pressure. We were always on time and the amount of work we were doing almost exactly fitted the 40 hour workweek. But since the entire development department was in a single large room, we did feel the atmosphere and hear the occasional yelling coming from our managers.

The day I realised something was definitely wrong was when this happened. My team leader and I were smiling over something and our boss approached us. “You guys smile too often. I’m gonna have to fu** that up for you somehow.” Those were literally his words. I was rendered speechless. What he actually meant was this: “You guys seem to have a lot of spare time, since you have time for smiling. I should direct some more projects your way.” In my opinion, the normal thing to say would be “Hey, looks like you’re on time. Great, lets have a beer after work.” But no, his boss is pressuring him so he is pressuring us and that probably won’t change. Of course, pressuring coders and switching them between projects almost never had the desired effect; the result was often software with a lot of bugs that would need a lot of fixing in the future. Naturally, I didn’t feel comfortable going to work anymore knowing that I should pretend to be extremely busy to avoid harassment.

Leaving that position for my current one wasn’t much of a hard choice.

 

Story nr. 2 – Never be afraid to fail

This is a positive one. Few months into my new job, I had to migrate the whole frontend from Bootstrap 2 to Bootstrap 3. To explain the problem very shortly: BS3 is not backwards compatible with BS2. And we have over a hundred templates used by our Django app. My largest commit consisted of over 70 files. I checked and double checked – but I didn’t check one of the main features of the site. Whoops. I failed to see the forest for the trees and as a result, for more than 30 minutes, our main feature didn’t work. The boss saw it before me or the other coder even realised what was happening and he wasn’t happy. Naturally, I fixed the issue within minutes, but that didn’t make me feel any better.

To be honest, I was sure I’ll get sacked the next day. But, I wasn’t, so I waited for the next day, because I knew it was just a matter of time. After few weeks passed, I stopped thinking about getting fired, but the whole situation still had a negative influence on me.

Last week, roughly ten months after “the incident”, I had my first review. When my boss asked me what was the most stressful situation during my past year on the job and what were the failures (his focus was much more on the positive, than on the negative, though), it was an easy question: BS3 migration. He didn’t even know it was troubling me that much.

His comment on the matter showed me what being a good boss really means. “You must never be afraid to fail in our company. I want you to excel, and you won’t be able to do that if you are afraid of failure. We learn from our failures and they help us become better at what we do. You will never get fired if you make a mistake. If you constantly make mistakes, that is a different issue and then we would need to talk. I want us to move quickly, to develop and grow and to do that, we will sometimes make mistakes.”

Follow your gut feeling when choosing a boss. If you do make a wrong choice, don’t be afraid to move on. Find the boss who doesn’t make you feel nauseated when you go to work and who supports your growth. Think about it.

Read more

tmi

Too much information. Too much information at once, to be more precise. It can happen sometimes when you are learning, especially with someone more advanced than you are at that moment. You hear so much, but after a while, it just becomes a sound, indefinite and unclear. And then you are back to the “I don’t know anything and never will” phase.

It happened to me many times; I was both the receiver of the information and the provider and because of that I believe I have a somewhat insightful grasp on the mechanics behind it:

1. The receiver is learning, he/she can be frightened and less absorbent to new information,

2. The provider often doesn’t realise how much does he/she know and is very comfortable talking about the topic at hand. The provider gives too much information because he/she does not know it is too much.

To illustrate a bit, I remember the first time it happened to me while learning to code. I met with this guy Mario, who was an experienced coder, and he wanted to show me PHP/web development basics in a few hours. The idea was not for me to be able to build a new Facebook after that session, but to understand the general principles involved, from setting up a server to writing some actual code.

At this point I’d like to stress that I was not a fan of setting up servers. At all. For some reason, it scared me more than writing code. After we set up LAMP (linux, apache, mysql and php) on my machine, which already took most of my concentration, he started explaining basic stuff like GET and POST. At that time, I was just beginning my second year of studying computer science so I was still a rookie and didn’t get to HTTP methods yet.

This was all happening very fast. He was talking and talking and talking. I was listening, but when we got to the end, I barely remembered anything he said. “I know this is a lot to take in” he said, “but it will settle down in time.” Despite what he said, I was feeling lousy. Back then I still believed that there are people who just know stuff, it’s in their nature – and I wasn’t one of them.

Last week the situation was opposite. I have a few friends who recently started learning to code. They use codecademy and they are learning the basics. I got into a quick conversation about coding with one of them; we both had our laptops with us. The day before, I discovered the Meteor framework and started using it for a personal project. It was simple to begin with and I was very excited. I wanted to show him how soon will he be able to do some actual work. His face went sour pretty fast. “What was that you clicked?” he asked. “I don’t understand any of it.”

He’s a smart guy, but I was the problem. I got so cozy with what I know I didn’t even realise others don’t know it as well. “If I understand it now, everyone will understand it” I thought. That is a very wrong opinion. And it can be dangerous, too, if you are in some sort of a leadership/management position. People need their own time to absorb information one at a time. Ideally, they need to sleep on it, let it settle.

Next time you reach information overdose, take it easy on yourself. It really will settle. If it doesn’t, go through the information one more time. And then one more time if needed, until you feel comfortable with it. Do not compare yourself to people who know more – you will be there eventually. It is important to compare yourself today with who you were yesterday. That is all.

Read more

theclick

Today I would like to write about the ‘click’. Not a mouse click or a remote control click, but the click that inevitably happens inside a programmers head when he/she starts viewing problems in a new, different way, due to practice and perseverance. A better way, or, as many like to say, ‘the programming way’. Here is a short story about my first ‘click’.

1001st prime number

During my second year as a computer science student I attended a very interesting class called Programming methods and abstractions. Today I teach practical exercises for that course, but that is a different story altogether.

During one of the first lectures, which were essentially the introduction to real programming (I dare say ‘real’, although we had Introduction to programming during our first year which was very trivial), the teacher asked us to think about an algorithm that would calculate the 1001st prime number. ‘That’s it for me’, I said to myself, ‘time to go home and admit this isn’t for me. This is for smarter people.’ But, when I overcame indulging in self-pity and defeatist attitude, I sat down and started thinking, opening a new C project on my laptop.

‘What are prime numbers, anyway?’, I googled because math was never my strong suite. Okay… Now, how do we calculate it? That part I didn’t want to google. I wanted to see for myself will I be able to break it. I had ups and downs, I wrote unneeded code, bad code, erased it, tried again… It took me three days of playing around and thinking about it to solve it. I was so very proud when I came up with this little piece of code (today I would probably write it differently, but this is the original):

#include <stdio.h>
#include <math.h>

int main() {

    int i, j, ok, c = 5;

    for (i=12; ;++i) {
        ok = 1;
        for (j = 2; j <= sqrt(i); ++j) {
            if (i % j == 0) {
                ok = 0;
                break;
            }
        }
        if (ok) {
            ++c;
            if (c == 1001) break;
        }
    }
    printf("The 1001th prime number is: %d\n", i);
    return 0;
}

I couldn’t wait for the next class to tell the teacher I’ve done it.  ‘Respect’ was his comment when I told him I did it and that’s pretty much the best praise one could get from that guy. ‘Maybe I do have a chance in this field’, a glimmer of hope appeared shyly.

The most important thing I learned was not how to calculate the 1001st prime number, but rather how to approach problems. It was the ‘click’ for me and it is hard to say more than that or explain it properly. It is an alchemical process, to be poetic. You change without realising.

After that, I took another task and tried to solve it. It didn’t take me three days anymore: it took two. The next one took one day etc. until they took a few minutes to solve. That was probably the first time in my life I believed in the power of practice. You should, too.

Read more

post03

In 2013 I got my first full-time job as a programmer (C# and frontend) at a startup in Zagreb. Before that I did some part-time coding, a website or two etc. I was super excited and I loved the job immediately. They were aware I was a beginner and treated me as such, helping me along the way.

At first, most of my tasks were very small and simple and I thought to myself, ‘hey, this isn’t as bad as I thought it would be’. Mostly it was just handling some CSS (I actually love that, unlike most my colleagues). Then, I remember the day, not long after my start, when the chief architect invited me for a meeting to give me my first project that needed to be done from scratch.

‘Okay’, he said, ‘our client saw this cool map on a website belonging to his competitor and he wants the same thing’. It was a Google Map with lots of Markers on it, which had InfoWindows attached to them (more here). The markers represented marinas across the world. I had to do the same thing and I was absolutely terrified and couldn’t understand why the chief architect is so damn calm and why does he even begin to think I could do it. ‘Now they will finally know I am actually an impostor’, I thought to myself.

The first response to something unknown can often be fear and/or as it was in my case, mild, silent panic. Lack of experience made it impossible for me to know, at that moment, that everything was okay. My boss knew what he was doing and why he gave me that task. If I had previous experience with Google Maps or something similar, I probably wouldn’t have panicked. Even if I had previous experience doing something at least a bit complex, I would know that every project of that scale is doable.

Before I even got to the maps part, I had to get latitudes and longitudes for our marinas. Before I knew it, I ended up making a JS script that loaded our bases and then called the Google Geolocation API (more here) for each entry, thus getting the data we needed. The API is not perfect and there was much noise, especially around Greece and Turkey since the names for places in those countries were often ambiguous, among other problems. But that is a topic for itself. The shocking part is that all that was not really hard to do. The documentation was good, I had stackoverflow at my disposal and the programming concepts needed to complete that particular tasks were pretty much basic.

That is when I started grasping the importance of breaking down bigger problems into small ones and approaching them one at a time. It is something you hear about all the time while learning to code, but it sinks in much better when you recognise it yourself in the real world. The rest of the project was very easy now that I think of it. Setting Markers and InfoWindows on a Google Map is an out of the box thing.

Despite the fact I learned a lot doing that small project, that doesn’t mean I wasn’t scared when the next project appeared. However – I was less afraid. And the time after that, I was even less afraid than the time before that and so on. And now imagine, what would you be capable of doing if you were not afraid?

Read more

yoda

Recently, my colleague made an excellent remark when I talked to him about how lack of self confidence influenced my beginnings as a professional coder. He said, “well, that’s because you were 25 at the moment, not 19-20 like most of your college colleagues”. And he was right.

A day or two after that I had one more interesting conversation with a younger friend who is thinking about starting to learn to code. Naturally, he’s scared because he thinks he’s too old.

Why do most of my younger colleagues have enough self confidence not to be freaked out? Perhaps, coding is the first thing they are trying to learn, besides mandatory school stuff and they have no reason to doubt or question themselves. They take it one step at a time and they are generally in no hurry. They know they will get there in the end. I don’t know whether that’s the case in the world, but sure is among most Croatian coding students.

On the other hand, if you are starting later, like I did, you probably already have some sort of a failed enterprise behind you – otherwise you probably wouldn’t be trying to switch careers in the first place. You were probably carefree and relaxed once, not thinking much about the future. Then you hit a wall and started wondering – how did I get here?

That was the case with me, although I was genuinely interested in coding to begin with, but I lacked the determination and confidence to start. Before all that, I got a BA in communication studies (de facto journalism). Being a journalist in Croatia is not easy because you often start with no salary what so ever (like I did) and you hope for the best. Hope is a cruel mistress, as they say, and with good reason. Suffice to say that career path didn’t take me far. I am sorry that social sciences and humanities are often not valued today.

To recap, I believe that the lack of self confidence spurred from previous negative experiences and/or failures. However, that doesn’t mean failures are to be expected in the future. Once you make peace with that, you can continue on learning without being in your own way. Also, and most important, being older than most of your colleagues doesn’t mean you are behind or that you don’t have the same chances as the others have. You have as much chances as you choose. As master Yoda said, “do or do not, there is no try.”

Read more

01

When I first started learning to code, I was both thrilled and scared. I was thrilled because I wanted to learn and do something both meaningful and profitable and I was scared because a part of me didn’t believe it could be done. To be more accurate: a part of me believed that I couldn’t do it, not someone else.

All the talk about the experts, ninjas and such made me sure I had already missed the train to Hackerville, me being a slightly directionless 25-year-old at the time. So, in order to compensate for my “late start”, I decided to learn a lot, attend all lectures and study hard for the exams. Despite the fact it started paying off almost instantly and I was getting some results, I was still deeply convinced of my position being somewhat behind others. (Will write more on that in a later post.)

Then, luckily, I’ve stumbled upon the term “impostor syndrome”. It is best if I quote Wikipedia:

“Impostor syndrome is a psychological phenomenon in which people are unable to internalize their accomplishments. Despite external evidence of their competence, those with the syndrome remain convinced that they are frauds and do not deserve the success they have achieved. Proof of success is dismissed as luck, timing, or as a result of deceiving others into thinking they are more intelligent and competent than they believe themselves to be.”

I was mindblown, to use the now popular term. Literally. It was probably the second* most important event that helped me through feeling lousy. Not the existence of the imposter syndrome itself, but the understanding of what the problem actually is. And I knew, finally, I wasn’t alone. Someone else wrote it, said it, experienced it and wanted to help others. (*The first event being coming to terms with lack of self-confidence. You can read more on that in the next post.)

Is it just me? No.

Read more