DEV Community: Alfonso Paredes Cervantes

The road to senior dev part 2

Alfonso Paredes Cervantes — Mon, 25 Jun 2018 15:22:50 +0000

Introduction

This text is a follow up from The Road to senior dev. What I want to share is some advice on how to be a well-rounded software dev and advance in your career to senior dev. Here I am covering a few points about best practices and your personal growth. If you did not read the previous post you can find it here: The road to senior dev. part one

Practices

11) We all know Kent Beck’s mantra, or at least we should
Make it work
Make it right
Make it fast
This doesn’t mean you have to go for perfection right away. First, make your software, do what it needs to do, doesn’t matter whether your code is not as clean as you want it to be, that’s what the second step is for. Refactor judiciously, remove duplicated code, simplify, improve your architecture… and finally, the third step is to optimize, not only for speed or resource consumption but also for the process, try to automate as much as possible.

12) Make it simple!
Complexity leads to coupling, coupling leads to high maintenance costs, and high maintenance costs lead to suffering. Complexity happens at all levels and one of the things you can do to avoid it is to frequently ask yourself the following question "Do I really need this?"
This question can be asked from a method level, where you should aim for a clean, easy-to-read code, to a macro level where the decision to use a library or a framework can seem to simplify some things at first glance but digging a little deeper you will find yourself coupling your application and, probably paying for this decision with a loss of flexibility later on. Make sure it's worth it, don't pollute your application with unnecessary code.

13) Tests and mocks are your friends
Sometimes you are reluctant to use unit tests and fakes, ending up testing your application all the way from the UI because you believe this is the only way to be sure that you are testing 'the real thing'. Well, the truth is, this method most of the time is cumbersome and represents a huge waste of time, the business logic really doesn't care whether the data comes from a JSON file or the UI.

14) Log of technical debt
Technical debt is a credit you have to pay, and often with a heavy interest, so you don't want to forget about it. It's ok to defer some things when the schedules are tight, but you have to keep a log for these decisions, so you can go back to clean your house later when the schedule clears up. Remember, the game we play is maintainability, and requires clean code.

15) Log of solved problems
How many times have you bumped into a problem just to remember back in your head you already solved it but can't pinpoint exactly how or when. I hate when that happens, so what I did is create a file where I log the problems I have dealt with, nothing fancy, is just a simple text file with a title for the problem, the project where it happened and the corresponding solution that sometimes is simply a link to a Stack Overflow page but this saves me a lot of frustration and time.

You

16) Continuous learning and new technologies
This is a hard profession for our brains, we need to be continuously learning new technologies just to keep up with the industry’s pace. Nowadays technology is totally different to what it was back when I started programming 20 years ago, so I had to learn lots and lots of new things through these years. But you must be aware of the following, companies don't like to change so fast, they are frequently risk-adverse and are not eager to try new technologies, they first need some assurance about the tool or technologies’ ability to withstand the test of time.

Nobody likes to spend a lot of money on something that could be deprecated for a new shiny thing in two years. So be patient when your technical leader is not so excited to use the new framework you just discovered. He is just playing smart.

17) Read the classics
I find the books by Martin Fowler, Ivar Jacobson, Uncle Bob… most interesting, because when you read them you are not reading recipes on the newest technologies, but rather deep reflections on why things are the way they are, tradeoff's implications, different points of view and sometimes colorful anecdotes.

18) Brain and attention
I read The Shallows:What the Internet is doing to our brains, a few months ago. This book had such a big impact on me and I recommend you all get a copy and read it too. This book is about the changes in our brain structure due to the use of the internet. How we are losing the ability to concentrate and to be creative while we pay attention to all those tweets and Facebook posts. At Zorbek we have been fighting this with mandatory reading time: The whole team, together, during business hours, read paper books, no screens and interruptions are allowed. And it has been working splendidly.

19) Drop the attitude and be kind
Please

20) Don’t burn your bridges
When you leave a job, you might feel the temptation to be rude to your now ex-boss and ex-coworkers, but please don't. There are many reasons not to do so. Probably all the grievances you may have now are not that important, and time will let you know that. Life is complex and the world turns around really fast, it is always good to keep doors open. And is also good for business, I am always getting business referrals from former bosses and coworkers and I’d like the same for you.

I hope you find these points useful, if you like to find out what we do at my company feel welcome to pay us a visit at Zorbek

The road to senior dev

Alfonso Paredes Cervantes — Tue, 06 Mar 2018 21:14:08 +0000

(First of two parts)

Over my growth as a developer that landed me to fund a software company, I’ve worked and mentor young engineers. A recurrent question I get is how to become a senior developer? This is not a simple question, every place has its own definition for what a senior dev is. However, from my experience working with several companies of different sizes and maturity level, I’ve found that to be a senior developer goes beyond simply to be familiar with certain technology. Actually, you must be able to make good decisions, provide accurate estimations and deliver on time on regular basis, among other things. The following points are intended for young developers starting their careers, despite more experienced devs may find them obvious, this list summarizes what I’ve seen a few fellows struggling with.

Project

1) Know the priorities and keep them straight: This point is better explained with this simple analogy: Imagine you are building a house and in the to-do list you have to install the toilet and paint the window frames. Of course, all things in that list needs to be done. However, for the house to be inhabited the toilet is indispensable while the window frames are not. (And you have the option to install the toilet or paint the windows frames. Of course, both things need to be made, but if you don’t paint the frames the house may still be inhabited, but if there is no toilet, it can’t.) This might be an extremely silly example and you may argue there was a project plan and budget already approved, but in real life plans change and budgets get cut. The idea to take away here is always be aware of what is most important at any particular time and make sure it gets done.

2) Avoid assumptions and make powerful questions: Assumptions are the root cause to many problems, and the reason I dislike them the most is that they are perfectly avoidable. You need to be aware of the things you don’t know for sure and make powerful questions to leave no room for ambiguity. For instance, imagine somebody asks you to meet at Starbucks at 8, then you reply with a powerful question to know what Starbucks branch and whether the meeting time is 8 a.m. or 8 p.m. Therefore, you won’t be at the wrong place at a wrong time wondering: If I hadn’t assumed ...

3) Analyze before starting to code: When we are young, sometimes we are eager to show our value and start writing code as fast as we can. However, it is faster to think ahead how you are going to build things, perhaps even draw a couple of diagrams, rough sketches if you will, but something that helps you to have a clear picture in your head of the hurdles you may have to sort out and the questions you will need to answer. Then you can start writing code in a more secure way.

4) Make good decisions: This sounds silly, right? But I don’t mean it in a, don’t drink and drive way, but rather in professional scenarios. And how do you begin making good decisions? First, list all the variables that may affect your decision, like: how ease of the implementation, experience with the technology, performance, cost, etc. Once you have all the variables listed do the same with your different options. Now you are ready to analyze your options, you can use a simple technique such as a Pugh Matrix to compare the different options and support your decision in a more solid way.

5) Know your customer: I’ve known people working on codebases with neither the knowledge nor the interest in what problem the software was going to solve. To me, that’s what we call code monkeys and they will be replaced by robots or cheaper labor in a not so distant future. When you care, it shows, and people starts to listen to you, and ask you for your opinions and value them. And so it begins, step by step, your responsibilities increase, and so are your value and opportunities, and consequently your pay check.

Teamwork

6) Don’t be afraid to ask: I understand you may be afraid to look as an ignorant to your peers or your tech lead, but believe me when I tell you that good teams love to ship software on time, and hate delays and their causes. So they will probably be more upset when you failed to ask something and, as consequence, the project is delayed, than if you asked something trivial but get over the hurdle and learn the lesson.

7) Don’t be afraid to ship: Declaring something as done can be nothing short of a traumatic experience when you are novice, but remember, we get paid to ship products, plain and simple. So, instead of trying to find excuses to delay your tasks: ship, deal with the consequences, learn from your mistakes and successes, improve and iterate until you are not afraid any more.

8) Respect your more experienced teammates: At times you may disagree with the decisions your technical leader makes, and that’s ok, but before getting all angry because she/he is so wrong, I propose the following approach: Ask the reason for her/his decision, try to see and understand the whole picture, perhaps there are constrains you are not aware of. In any case it will be more useful for you to understand the decision-making process than simply throwing a tantrum because somebody disagree with you.

9) Balance between blind obedience, reckless disobedience and covering your ass: Let me tell you an anecdote to illustrate this point. I was working on a project as a Business analyst and among my responsibilities was writing some stored procedures where business rules were enforced. The customer acceptance test was to be carried in China and our technical leader had to fly there for the test. About a week before the release to the user’s test environment, the technical leader told me a business rule was wrong and how to fix it. What he told me did not make any sense to me and let him know that respectfully , when he insisted that I should change the stored procedure for the rule I asked him to clarify exactly what he wanted by email. He did and I proceeded to flag the message so it would be easy to find it later. Also, I made a special backup for the stored procedure code so I could grab it right away when needed. A week later, when testing in China that very same business rule did not pass the acceptance test and I got a phone call from my technical leader asking me why it was programmed that way and who asked for it. I told him, again respectfully, you did, let me forward you the email. So,30 seconds later he asked me how long would take to change it back. Right away, I just have a backup at hand. The moral of the story is sometimes you are right and your boss is wrong, in those cases I found better to ask for clarifications via email or any other traceable means and perhaps reply with your proposed solution. So, in case any problem arises you are covered and the right solution documented. You may think this is unnecessary but sometimes bosses throw subordinates under the bus, so I recommend being smart about it.

10) Answer emails: Please do so, if not for other reason by common decency, sometimes a simple Thank you! Or acknowledge will suffice is enough, and that makes a ton of difference versus not replying at all.