Although we are developers and we like to code, we need to be social in order to do our jobs properly. When you are just a code monkey, closing tickets on your Jira board you will burn out very quickly. Have you been in that situation? You know, day after day, week after week, just picking up whatever is highest priority on the SCRUM or KanBan board in order to make some deadline? Not discussing any high level design, contact with customers or knowledge transfer with colleagues. You do not have any say in what tickets are supposed to be picked up and you do not have any input on how it is supposed to be implemented. All of this is passed down to you by someone else. Now how much fun is that? I’ll just say it for you, it sucks ass.
So communication is a critical skill for any developer, hell, every human to have. And in the book, the authors present us with some tips on how to be a good communicator.
They start of by saying; you should know what you want to say. This is mostly important when you are in a high level business setting. In formal styles of communication it can be difficult to find a proper way to describe what you want. I’ve been in both business settings and start-ups and well, to me the start-up vibe is more attractive. It just resonates more to me than a formal business environment where everyone is required to be dressed in expensive suits where you are unable to move in. But that’s just me, being a millennial I guess. I’m also a big fan of remote work and flexible working hours.
But yeah, know what you want to say. Sometimes, when you don’t know. Write it down and start with an introduction to the topic. When you write things down it will really help your brain to process things. You probably heard that before, and it really works, I do it all the time.
Their next tip is to know your audience. I hinted at this just now. Being in a formal business setting compared to a start-up setting will definitely be a different audience. You can’t really build an entire presentation out of meme’s when presenting to business people. But maybe in your start-up or presentation among developers you fancy meme driven presentation lands very well. This also concerns the information you are about to talk about right. If you need to explain some project you’re doing to business people vs. technical people, you might be able to dive a bit deeper into technical details while talking to the tech crowd.
But knowing the audience is one thing, what is also important is to choose the right moment. If you call in your colleagues for a knowledge meeting at a Friday at 16:00 you will most likely not be successful. Maybe if you add some beers and food they might join, but how much will they learn? Also, when you know people are very busy, maybe trying to beat a deadline it is probably a very bad moment to ask them if they can update their unity version. They will shrug you off as an annoyance. And updating that Unity version can probably wait anyway.
Another aspect of good communication is to choose your style. Sometimes a quick slack message is sufficient. Some other times you write proper email or you might even plan a meeting to discuss things, depending on the topic and importance, or maybe the project, business or financial impact.
It just really depends on what it is you need and why or when you need it. Depending on your style it might also be easy to involve your audience into the discussion or conversation. This is always a good idea by the way. If you involve your audience, you are not talking to a wall. Plus it will also force you to listen. Which is required for good communication and it’s crucial part of receiving feedback. You really need to be able to take feedback. I think I have talked about this before, while discussing the Clean Code book. If you see feedback as criticism you will not enjoy your job as a developer because, every other developer has an opinion about code. You need to be able to take feedback however bad it might seem and make the best of it. It’s just part of life. If you are stepped on your toes easily you will suffer. And if you disagree with feedback, have a discussion about it because there is most likely some middle ground to be found. It doesn’t always have to be polarizing. This is what good communication looks like.
And the very last tip they give is to always come back to people when you tell them you will. Yes, this is very important because it will annoy the heck out of people when you don’t. You’ve probably been in the situation where someone told you he or she would get back to you, but never did and never will. This is annoying and will slow you down because you will continuously need to ask that person for his or her input. And at some point you will start to ignore him or her, which will not improve the company culture.
So that was it for the preface and the first chapter. It’s been pretty long I see. But let’s review what we talked about for just as second. The authors gave some insights into the pragmatic philosophy. They started by saying you as a pragmatic programmer should care about your craft, think about your work and take responsibility. Not just responsibility of your work, but be proactive in progress and work related things. So don’t wait and sit until people show up at your desk, go out and stand at other people’s desks and be proactive haha. And when you do, don’t give lame excuses but provide options and solutions. Try to be the catalyst of change while still remembering the bigger picture. Remember the frog being boiled? He totally forgot about the bigger picture. He was just enjoying a warm bath until it was too late.
The authors also spend rather much attention on the topic of your individual portfolio. I think this is crucial nowadays. If you are looking for a job, but do not have a nice portfolio, your 4 year degree might just not help you as much as you think. And the ecosystem is changing. There are multiple high level companies that are not expecting job applicants to have degrees, but do have a decent portfolio to prove their skills. Personally I think there should be a middle ground. In certain fields, your degree will definitely come in handy but I agree if you just want to do some front-end webdesign with popular frameworks like React, Angular or Veu, some bootcamp might be enough to land you a job. But if you are deep in the weeds designing and developing low level services for example, then your degree and formal computer science knowledge will most certainly come in handy.
I’ll give you a quick example; At work I do some back-end work as well as Unity3D. At some point, a front-end web developer came to my desk telling me the back-end was doing weird while saving some data. He said he made some copy paste functionality but once he changed any of the copied data, it changed everywhere he pasted it too. This is the classic issue of reference types vs. value types. So I explained it to him. This is not a back-end thing, this is a problem in the way he used some javascript array copy logic. He needed to make a deep-copy, not a shallow-copy. But he being a true front-end guru, a brilliant creative developer just never heard about this. Which is understandable but I still think this is a nice example to give. Cases like this is where your formal degree might come in very handy.
But alright we were talking about keeping your portfolio recent. It is very important so, really, spend some time on personal projects and create a nice portfolio. So invest regularly into your portfolio and diversify. Learn at least one language every year, and remember you do not need to be an expert but just know about the general concepts a language is built upon. Read technical books, and listen to podcasts, especially this one of course. Take classes, courses and or bootcamps to improve your skills.
Be a critical thinker and always communicate to the best of your and your peers abilities. Know what you want to say, know your audience and choose your moment.
That’s it for chapter 1! Next time we will continue and make a start on chapter 2.
#end
01010010 01110101 01100010 01100101 01101110
Recent Comments