Your partners in accelerated digital transformation
This article by InRhythmer Josh Villahermosa originally appears on Medium. For the full text and additional resources, check out the article here.
When I first started using Vue, I was blown away by how easy it was to use the CLI. I was more surprised to find out how easy it is to create a re-usable Vue project using the Vue CLI. Here’s how: Read More
This post is another by InRhythm’s own Josh Villahermosa. For the full post, relevant pics, and additional links, check out the original “Personal Planning Using Agile” on his medium.
Maybe there are times where you think you can have the most productive week ever, but in the end, you accomplish so little. Maybe you find yourself overbooked and often asking friends and colleagues to reschedule the next meet up. Working in the software industry, I picked up planning processes and techniques to help estimate when a project will get done. Applying the same processes to my personal life help me understand what I can do realistically and keep track of the things that need to be done. You will be surprised at what you can accomplish with proper planning. What I will show should be taken in the lightest fashion and encourages modification to fit your needs. It is an iterative process that allows you to measure your personal performance throughout the week. Here is how to get started.
The Pomodoro Technique is productivity hack that allows measuring your time working and encourages high productivity. How it works is you take a task to focus on for 25 minutes. After that, you take a 5-minute break, and at the end of that, you work again on the same task for 25 minutes. After 4 iterations, you take a long break which is typically 10 to 20 minutes. The key is to really focus on that 25 minutes of work and take the 5/10/20/etc minutes to recharge (look at messages, Imgur, etc) or take a higher level view on where you are in the task. This allows you to work on the tasks longer and reduce fatigue. This is also great for estimating how long tasks will take. You can say it will take 3 Pomodoro’s to write this article. Later I will show you how this will relate to scheduling.
Kanban is a process that has come out of Toyota’s manufacturing process. It is a simple process of having items in columns (typically To Do, Work in Progress or WIP, and Done). They will start out usually in To Do and move in one direction from left to right, making its way to Done. Find a good online Kanban tool to use. You can use Trello which is free and very easy to use. For the purpose of this article, I will use Trello as my main Kanban tool. On Trello, create 4 columns: “To Do Soon”, “To Do”, “WIP“ (Work in Progress), and “Done”.
I’ve grown a lot as a software engineer since I graduated college. Many colleges don’t teach real world interaction with a team and common coding standards. If you are just starting out as a developer or are more on the junior side, this post is for you. Many of my points come from real world experience and the mistakes and learnings I made along the way.
Expect a lot of comments on your first PR.
Just remember this is normal for starting developers, especially those who are fresh out of college. Co-workers who have more time and experience will point out flaws, spaghetti code, or over-engineered code that may be hard to read. They may have a certain way of writing code that they expect you to conform to – this is all okay. As you work on more and more stories and receive feedback from your peers, those comments will gradually diminish in number.
Writing maintainable and readable code is just as important as getting the feature done.
When you were in school, you might have written a lot of code expecting that you would be the only one who could read and understand it. Perhaps your professor only cared about whether the thing you built worked or not. In the real world, you will most likely be working in a team. Even if you can finish a feature a few days before everyone else, it will be useless to the business and the team if you are the only one that can understand it. Naming variables and functions well goes a long way. Being consistent in your codebase also helps. If you switch teams or move to another job, and you have left behind unreadable code, your former team will have a lot of refactor work to clean up on your behalf. Good code is simple. The easier it is to read, the more value you add to the business, not to mention the better relationship you’ll have with your team.
If you are not sure about pointing stories or time, over-estimate.
For those who work in an agile process (Scrum in particular), there is a good chance that you will have to point stories. If you are not sure about what your acceptance criteria should be, ask questions. If your team isn’t sure about the story, ask for it to be a spike (a task for gathering information rather than delivering a feature). If you can identify clear parts of the story that are defined well, ask for the story to be broken down into small digestible chunks. If you understand the acceptance criteria, but don’t know the code base, then factor in the time and degree of complexity to understand that code and seek guidance from someone more senior.
The simpler the code is, the better it is.
There are times when you want to handle all possible situations when developing a feature. Be wary, as this can lead you to over-engineer (build more than what is required). Employing TDD in your development process will help prevent over engineering and keep your code simple. A good code review culture is also imperative to prevent this from happening.
The company may have a certain or specific style of coding.
Throughout your career, you will inevitably pick up certain styles of coding, as not all companies adopt that same style. Focus on the present and your current objectives, wherever you are – try to understand why your employer or client has chosen that style of coding and how it helps the business.
Focus on learning AND the job-at-hand.
As a junior software engineer, you should be learning something new everyday. It doesn’t have to be about the best coding paradigm or language; rather, it can be about the business or something you didn’t know about yourself.
Sometimes you might feel like you are stuck in a rut. This is a good opportunity to re-evaluate your current situation. Are you taking any steps to learn more about the process? The code? The business? Is there anything you can do to improve the business overall? Reach out and see what you can find. If you feel like you have done everything you can to learn about the business, then it might be time for you to move on and find other opportunities.
No language or framework is a silver bullet.
There are constant arguments and favoritisms about a particular framework or language. “React is better!, ” “Go is more performant than Node,” are just a few examples of opinions you’ll hear. What really matters is the mindset that all frameworks and languages are tools to help meet business requirements. Choose the best one for your use case and get the work done.
Finding a mentor is essential for your professional growth.
Regardless of whether you’re assigned a mentor on Day 1 or you seek out a senior team member to serve in this role, having a mentor is key. If you’re lucky, you will identify with two or more mentors that will debate with each other on which methodology is better. Take the time to learn from your mentors – it is the fastest way to become a senior developer yourself.
It’s okay to make mistakes.
Don’t panic! I know it’s easier said than done when for example, you accidentally force push to master (don’t ask!). Like driving, the worst thing you can do is panic. When you make a mistake, seek help immediately and explain the situation in full detail. Even if it’s a major mistake, you are helping expose a weakness in the process which can be refined to stop similar mistakes in the future.
Ask questions if you are stuck.
Of all the things I’ve learned on my way to being a better developer, it is to simply ask questions when you are stuck. Time-cap it when you are stuck in a problem. Try thirty minutes to an hour. Try listing out possible solutions and go through them one by one. Once you’ve exhausted your ideas, seek help. Another pair of eyes can help open new perspective on a problem. This can also help build relationships in a team and achieve a win.
