Junior to senior

Introduction

• Always think about the business value your works is providing
• Think about the feasibility of a requested feature - is there a better solution to it
• When you have free time, look at what other teams are doing. May be help out if you can. This will give you visibility into other parts of the organization and create a bigger impact.
• If you really can't find anything, documenting a complex project you did or a library that was used can always be helpful
• Senior developers are not scared to look at the source code. If there is a bug with a library you are using and Google search doesn't return anything useful? Take a look at the source code of the function you are using. You might be able to find the problem or at least get insights into the solution

Who is a senior developer

Proficient

• He writes high quality code according to best practices there are
• He is aware of technologies and methodologies outside the organization he works for and the relevant technology and methodologies inside the organization
• Finds and solves bugs quickly

Manages himself

You just assign him with a task he should perform. And he prioritize and handles them in the most efficient one as possible.

Professional

• He brings value to the organization he works for.
• He decide how to invest his time and how to spend the resources he is responsible for in the most efficient way as possible.
• Striving for exellence. Continually improving in all relevant fields

Team player

• He looks beyond his tasks for ways to promote his team.
• He acts selflessly for the team benefit.

Excel

How to make you excel in the two basis skills you need as a developer: Completing tasks and solving bugs.

• Why is understanding the task important? How to make sure you really understand it.
• Solving: what is the step to reach the optimal solution for a task
• Implementing the solution: the methodologies. What's considered a good coding session, where to start writing code from
• Testing: why, how, how much
• Bugs: how to solve them from start to finish

Understand the task

Sovling a task:

• Have a specific document -> clear understanding of the task

Why invest time in having a deep understanding of the task before coding?

• Less bugs
• Minimize changes after coding begins
• Better time management

Understand the task - Showcase

• You understand the task when you have a mental clear image of it. You can see it's working in your mind.
• Basic understanding questions:
  • What does the user see?
  • How does each part behave?
  • What interactions is there with other components?
  • What are the edge cases,and how to handle them? Edge cases are the non-trivial states of the system. Edge-cases: what if network failed while the file is being transferred?
• The destination doesn't have enough room for the file?
• What happened if the system already has the file with the same name?
• What is the max file size that can be copied?

Solve

• No reinventing the wheel
• Write compatible code, naming convention, where to places file in the project and so on. Our code should be compatible with the project.
• Not waste time on implementing sub-optimal solutions. We want to get to the optimal one as quickly as possible. Implement that rather than any solutions. We don't want to find out later that the solution doesn't work

What are the scope and context?

Scope

• What already exists? You must know wherether or not some usable components exists or you'll wasting time write one.
• What needs to be done?

Context

• Parts of the system that interacts with your code: Exception mechanism, Logging mechanism, how to integrate those into your code. You should find relevant function you should use and think about how to use them.
• Code you can learn from or use: May be there is some functions similar to the one that you're going to write which you can get inspiration from
• Coding standars: naming convention, putting files where they belong to, writing funciton in the right place

Find optimal solution

• What are some relevant solutions?
• Which solution is the optimal? Why? Criteria for comparing solutions
• Cost
• Performance
• Forward compatibility
• Simplicity
• Security
• Completeness - handles all cases
• Coding standards and conventions compatibility

How can we be certain that our solution will work. For some solutions, the answer is trivial. What should you do when there's doubt. Going ahead and building the solution you're not sure of might prove itself to be a huge waste of time. Use POC(Proof of concept). You find the problematic path in your solution and do the minimum needed in order to make sure how to handle it

Implement

• What is considered a good coding session?
  • Concentrate solely on solving a specific issue
  • Clear image of what you're trying accomplish
• Where to start writing code from?
  • The main flow Utilize Review before implementing:
• Beware of all the taks's detail
• Concentrate on the big picture
• The main flow is where you should start coding
• Make sure what you created works exactly as what you intended

Test

When a developer try to break what he've just built, he's having a hard time thinking how. The challenge here is changing the mindset

How much to test?

• As much as it takes for you to be sure there aren't any bugs

When to test?

• As soon as possible. The reason is that you want to be certain that if you do find a bug it because of the latest code you wrote but not something older. When each part is tested as you completed, you can start the next part being certain that the bug you find has to do with the lastest code you just wrote. Rather than having to go back at look at bugs in all previous part

Debug

• Know your toolbox, debugger
• Document:
  • Document what did you try, and what results did you get?
  • What clues did you find?
  • What do you plan on doing next?
  • Everything else that might help
• The bug you are trying to solve is not actually a bug
• Find and understand your error message. Read error message carefully
• Find the exact point of failure
• Understand the flow of the code, reproduce locally
• Refactor to improve readablity
• Doubt your assumption. Ask your self, what did I assume to work correctly and hence not check properly. Make sure you are not spending your time on the wrong place. Finding somewhere
• Avoid chaing code you don't understand

Missed a detail

Imagine you miss a detail in the requirement while you was reading the spec. Low quality code is very expensive.

• Always look for unclear issues, and make them clear.
• Always know where you are in the bigger picture
• Always make sure what you know is available to you

Learn

Set yoursel goals

Have a vision where you want to get professionally

Know your resources

TIME TYPES

1. Free time in front of a computer
2. Time at work:
   1. Work in an organization: work with manager, team members and so on.
   2. Completing tasks
3. Free time not in front of a computer: Drive to work, take a train, take a walk for learning

TIME - USING IT WISELY

1. Learn only what's relevant and benefecial to you and be ready to skip everything. Use every minutes effectively
2. Enjoyment and satisfaction are key

Theoretical learning

• Books
• Blogs
• Other people's code Listening
• Podcast
• Learn techniques, not tools: Programming language, tools, and methodologies come and go. Pay more attention to architecture than to programming

Pratice


Plan your path

The power of habit. After you get yourself into doing something regularly for certain amount of time. You keep doing it after that amount of time with very little effort. 3 Approaches to build a plan:

• 1. You plan what you do for each and every day of the week. Use the power of habit
• 2. All in: Set yourself 1 goal, devote all your time to accomplish it. For example: Complete my pet project by next month. This approach keep you motivated by giving you one single big goal to achieve rather than many small ones.
• 3. Combination of the two. This approach is the most effective

Imagine

• Where you want to be in a few years?
• What are the most relevant topics?
• Build a plan & stick to it Alber einstein

  If a person studies a subject for 15 minutes a day in a year he will be an expert. In 5 years he will be a national expert.

Take the next step

Time management

• You just can't estimate how long you don't understand or take
• Reduce risk by starting with the most dangerous part of the task with proof of concept

Steps:

1. Estimate how long the task will take
2. Make sure you have what you need as soon as possible
3. If there are delays, reflect them to your manager
   • A problem you reported long before the deadline is a problem
   • A problem reported shortly before the deadline is a crisis

Recommend new technology

• How long will it take to implement this technology in the project
• How long will it take you and other team members to learn it?
• Does this technology have known issues? What are they?
• Is it stable?

Saying "NO" to manager

• Sometimes, the person who assigns you a task doesn't understand its full implications
• It's our duty to reflect that to our managers

The zone

• Detach yourself from everything from you
  • Prevent interruption: Work early, leave work late, put headphones on, close all messaging applications. Get everything you need
  • Focus: Have clear goals. Don't start the session until you know what you're going to do. Devote yourself to do the task.

Stand out

1. Ask why?
   • What does the user see?
   • How does each part behave?
   • What interaction is there with other components?
   • What are the edge cases, and how to handle them?
2. Help you team achieve its goals
   • Understand what's your team leader is trying to achieve
3. Become a guru
   • Choosing a technology, business process or area in the code and geting to know it really well, be the person people come to when they want to work with it and you definitely stand out.
4. Lead
   • Every now and then, you'll be asigned with task that you share with other developers when you do, try to be a little proactive and to be the one who is aware of the entire task status.
   • Make sure what you do is accepted by your teammates and not considered rude or unpleasant anyway

Kaizen: Continuously improving

- Number of bugs per task

- Time estimation accuracy

- Number of comments in code review

Did you get better on those parameters on your last task, compared with the task before that?

Scale

Reflect

You need to stop at every meaningful step you do. Be a big task or a ciritical bug you found. Ask yourself, how does that go? How effective was that activity.

Awareness

Constantly keeping in mind trying to see if what you're doing can be done better. Be aware of small steps.

Comparing candidates models

1. Motivation

• If I see a candidate with low motivatoin, I won't hire him.

2. The inheritance model

• A software developer should have a good technical level: He should be aware of the relevant techniques
• A profressional: reliable, responsible, provide high-quality solution and so on. You don't want to work with a software developer who often promise that he'll complete task but he doesn't. You don't want to work with a software developer that build things that break easily.
• A human: honest, kind, humble, have modesty(humble). No one wants to work with someone who is bragging about how he solved that problem all by himself when everyone else didn't have a clue.

Vision

Making an effort to become a little better person every day. The ability to put your ego aside and do what you think is right. A good team player is someone can put ego aside and act professionally and humanly even when it's tough and doing so for long period of time I believe make you a better person.