Becoming Intermediate -Growing beyond a junior software developer

I think junior, intermediate titles belittle people and their capabilities/talents/skills.  Where as sometimes the senior title can over in-flate your capabilities, whilst belittling others. We as humans love our labels as it allows us to understand what we are talking about or get the context faster. They also limit/focus our understanding and can make us lazy, in fully understanding a humans’ capabilities. Particularly if they have multiple capabilities. And lets face it, software engineering has many different capabilities, approaches, etc.

Working with others

Its not just about you anymore and you learning code, of course that will always be a big part of it. Its what you do with that knowledge, how you share it, how you take on advice, how you help others grow and of course building something that people want to use. Your perspective changes.

It changes in that you no longer look at a problem the same way, its not just the feature and what code you will need but how will this feature affects other features, the dependancies map out for you.  Your ability to problem solve becomes more complex, faster..

I have broken this down into the four aspects of what I have seen.

1. Being a better human and using code for good
2. Growing technical competence
3. Understanding the big picture
4. Building something useful

Being a better human and using code for good

As we get better at understanding what we are doing, in theory we should also become better at communicating it with our peers, as in other developers but also to non-developers.  I feel there is intrinsic value in sharing the growth journey.  In all fields, the master will have much to learn from the apprentice (I’ve learned so much from my students, interns and co-ops).  The best way to refine your skill is to teach, even when you are at a high level.

Explanation of the simple things

It seems you will spend more time explaining to “Business Types” the need to

• Reduce technical debt e.g. not build on a house of cards, the risk higher to not tackle this problem..
• The need to refactor e.g. imagine saying what you think, before filtering, do you always send the angry email or do you edit it?
• Why tests are important e.g. so I know when something is broken before a paying customer or that key investor?

Having good analogies will really help.  Match these analogies to the interests of the person you are talking to.  The more analogies you have, the easier winning the “debates” will be.  Your other duty here is the is to balance yourself – does it really need to be that secure, that fast, or that perfect? Compromise is often needed between humans and their different interests i.e. technology and business. Remember no revenue or growth, no money, no wages..

Taking time to review all pull requests

Before I would let the “Seniors” weigh in on the pull requests.  Well I am now the most experienced in Rails in my current team, kind of scary, there are no seniors.  I have to figure it all out as it comes. This drives me to learn more, both tactical and strategic learning (explained below). Also when I do not know or understand I get the developer to explain the what and why, until I do. Interestingly this process is kind of like interactive rubber ducking (where you explain the problem out loud) and sometimes we have discovered problems together or I have learned something new 🙂

Spotting trends – the continuos code review

Helping people change behaviours and habits. This is easier if you can help people see specific code and have a good solution.  Always explain the ‘Why’. Habits take time to change, be patient. If you are, they may copy your behaviour and be patient with you. Kindness breeds kindness and critic breeds more criticism, where do you want to work? Of course there is a balance our job is often rational, but us humans are not.. Yes you may like to pretend but you are not Spock or a Sociopath..

preference => { :hamster 'true' } <<- Would this work with {:hamster 'true'}? 
vs {:hamster => 'true'}

preference: { hamster: :true } >> preference: { hamster: true } (unless symbol 
explicitly desired, would object true be more desirable?)

Thanks for the example Zachary Moshansky

Sharing rather then deciding

As a leader (software dev was not my first career) I have often stepped back to let others explore, gain confidence and grow their Leadership skills.  I find myself doing this more as a software developer. Yes I have ‘an answer’ but I will introduce it only if needed.  I no longer need to prove myself.  Let others try before giving the answer, pushing your brain a little, helps a person test and experiment (core to be a good developer).

Creating a culture through your own actions

I laugh a lot, generally at myself. “cultural leaders” help change an environment through their actions more than their job titles.  Cultural leaders are not always those with “given” authority i.e. through a job title or description, but earn it through how the teams thinks and feels about them. Reward behaviour you want to see repeated. But be careful that a person does not overdo it. Balance is important, turning someone into a workaholic will be detrimental in the medium and long term to them and you, when it goes pear shaped..

External Peers

Talking and exploring code with others I always find powerful, particular if its a dialogue and ego is removed. A conversation where two people share.  There often times I seek out the opinions of my peers either through taking a developer out for lunch from another company or use a site where opinion is allowed e.g. RubyRogues.

Interviews

I have talked about this in previous posts, just to say think about how you would get the best code out of you in a technical interview.  My favourite technique so far is to pair code with empathy. To ask questions that relate to your real work. Also to realize the vast majority of humans do not perform at their best in an interview, so how can you help them bring a glimpse of it out..

Growing technical competence

Skills

In the end you are measured by your skills and delivery.  There are three skill sets you need to grow as a developer

Technical Skills

• Language skills e.g. C, Ruby
• Testing e.g. RSpec
• Framework e.g. Rails
• Tools e.g. text editor, FTP
• DevOps e.g. AWS, New Relic, Google Analytics, Capistrano, Ansible
• System Design e.g. Domain Driven Design

Brain Skills

• Ability to learn – what are your learning styles?, how do you remember?
• Problem Solving – how do you keep sharpening this?
• Concentration – what is your best environment? best time of the day?
• Abstracting – what helps e.g. whiteboard or something else

Communication Skills

• Explanation of complex things – analogies, stories
• Negotiation
• Team player
• Leadership
• Conflict Resolution
• Feedback – giving and taking

There is also something else very important and that is fit.  I would personally would rather work with someone I enjoy working with (and maybe less skilled) rather then a misfit who is brilliant. The impact on team morale i.e. happiness, dramatically affects productivity. Often teams interview for one of their own (a misused version of fit), this can be missed opportunity to grow the team to the next level.  Avoid clones. Get to know people, I would suggest before you know their code, sometimes you will meet people that you will want later in your journey..

Keeping up – Tactical and strategic learning

I thought I had to do homework before, but its seems that now the homework is at a more abstract level. Code styles, refactors styles, and now I am not focused on just what need, but on what the team is all working on.  Day-to-day you have learn/research how to solve the bug or create a feature – I called this tactical learning.  Then there is the bigger picture e.g. the application of object orientation, MVC or other patterns.  This I call strategic learning, some of this you will have done in a Computer Science degree, but may have to learn how to actually apply in your current language and/or framework. Of course if you did not do a CS Degree, you need to make times to learn this.

Tactical Learning

Google the problem/feature, stack overflow, google groups, podcasts that come with forums e.g. RubyRogues has Ruby Rogues Parley which allows you to ask for opinion which at times is more helpful then QA websites like stack overflow

Strategic Learning

Books that talk about patterns, anti-patterns and architecture, how you organize your code help you take the next step up. Patterns are useful vocabulary, but do not get blinders, everything in moderation.  Examples in my journey included Rails Antipatterns: Best Practice Ruby on Rails Refactoring and Design Patterns in Ruby

Places to look Goodreads.com for Books, or Coursera for free theory courses.

Growing your perspectives

Yes I would love to be an expert in Rails and Ruby.  As you become comfortable it is time to explore another perspective for me that will be going deep with JavaScript and Angluar.JS. Each language you will learn often make you better at all the languages you know, they will give a greater context for understanding programming, they will give you greater flexibility in roles, problem and challenges you can take on. As we know every language will evolve or die, just the same as everything human.  To ensure your future, play and experiment with new languages, stay curious friend.

Technical growth

I find adding in some different sources of knowledge and wisdom that are not also related to by immediate work help, so I subscribe to Ruby Tapas, RailsCasts, DestroyAllSoftware and http://rubyweekly.com.  I like video because I feel like I have to read so much, that it gives a bit of a break and occasionally I will listen to RubyRogues podcast.  As you can see I use different senses, and formats to make my learning easier.  I also love books, yes the ones made from paper, you can see my collection here https://www.goodreads.com/ericbrooke.  I also have become very interested in how people teach the same concepts, firstly so I can see what helps me to consume knowledge faster and then because I want to help others grow. All of that said experimentation seems to be the most effective for me to learn and for me to retain what I have learned. When trying out a new Gem I will often create a new Rails App and add the gem and play..

Things you should know:

• How to test your code
• SOLID
• DRY
• Domain Driven Design
• Design Patterns and how to apply them
• The importance of clean data
• How your whole stack works
• How do measure your code e.g performance, memory usage
• Start learning System Design
• If you are working in a monolith, learn about microservices

Isolation

I used to try to change too much in one go. Now I will (mostly) change one thing and check before moving ahead.

A touch of obsession

Sometimes it feels like we have to become obsessive about that new skill for a while, to get to know it well, see where it breaks and then dial back.

Introspectives

Each week we have a meeting to look back at our code and talk about some of difficulties we encountered and how we solved it. Each developer gets sometime and I also pull together a number of videos talking about some code/language/architecture thing to share. This is a developer only meeting, no founders/product managers our purpose is to learn from each other.

Note-taking

On this job I worked on a Rails upgrade from from 3.2 to 4.1.  with over 100 gems in it, I took the opportunity to take out all the non-supported gems, there was name-spacing changes in some, frankly there were incredible number of moving parts.  It was taking notes that saved me more than once.  I also documented errors and how I solved them i.e. copied the error and the solution, it was interesting to go back after the process and evaluated my solutions.

Concentration

How do you get to the zone and stay there.  When during the day are you good at the tough problems i.e. for me its the morning and about 3.30pm I could nap or grab a coffee. What breaks you out of the zone? What music on your headphones takes you to another place where you can write efficient readable code.

Problem Solving

The way you think is valuable.  Not all of us tackle problems in the same way.  As software people we lean into a very scientific approach of experiment and see the results.  That said sometimes its is a smell, that we cannot put on finger on the whole details, unless we have seen it before, our intuition may led the first step. Understanding how you break down problems will help you.

A great talk at Railsconf by @geeksam that would apply to all problem solving can be found here http://www.confreaks.com/videos/3391-railsconf-cognitive-shortcuts-models-visualizations-metaphors-and-other-lies

Understanding the big picture

Its not just about you, or even your team, the department or just the company..

Working with business

The code is never perfect, but we can see many ways we want to improve it, sometimes it will be a speed gain, other times easier to understand, making on boarding of new developers easier or faster feature builds as you have a better foundation.  That said, if there is no one to pay the bills and your wages.  As most things in life we are building on something imperfect, yet we need that feature to attract users who will pay for the use of the application.

Architecture growth, getting the big picture

We can often it driven by ‘Feature completion cycle’, or importance of velocity. This can lead to less reflection, less understanding of the business, less thought on the big picture or of the monster we are creating. It is a common trend for startups to build several generations of Apps, as the initial core App was mutated to do many ugly things to add that feature that you needed.

eBay gives 20% of the development time for the devs to work out what they need to do i.e. no features.  This is put into refactoring, experimentation, etc. They learned from having to rebuild the entire App several times.

Good Architecture also allows for a faster on boarding, and the confidence to not always employ very experienced coders and build a healthy ecology of experience levels in your team.

Understanding the moving parts

Whilst I am not suggesting that you know everything, do get to know the important things  from product, marketing, UI/UX/Design, sales. Respect the other cogs in the organization, will help you grow your overall business understanding, maybe even grow your friendship circle, or even find a great co-founder for that startup you want to get going..

How we behave around here

Organization culture, the stories, the myths, the symbols, how leaders and followers treat you, does the organization trust you or does it enforce it? When you get wrong, how does the organization/people forgive you and when you get it right how does the organization/people celebrate?

Understanding of Technology

This is an unfinished thought, which I will come back to.  There are some technology organizations where the CTO or the VP of engineering are the only people that really understand technology.  If they are unable to advocate effectively for the coders in the organization, they appear to become feature shops, driven like factories, where the coders are mere cog works to manipulate, where the pressure is always on and there is no time for reflection and learning.

Building something useful

As a software writer of whatever type, you generally want to build something that is useful.  Something that people want to use.  Whilst some founders/product people would like you to only build what they have determined as useful, I would suggest you are not just a software writer, you have opinions, thoughts and so do the users.  Sometimes it pays off to have raw data and form your own filters/patterns.

Knowing your users

In the end its really all about your users. Knowing your users will help, and not just your impression of what you think they are like. Get to know your market and its people.

Analytics

Have analytics systems embedded in your applications, watching behaviour from a scientific perspective is very helpful. It is only part of the equation but a measurable form.  The chances are you will not always measure everything you need in the future, so make the integration easy and expandable. Also note the actual server processing cost of whatever packages you use. All of that said analytics can be dangerous, mis-used and soul destroying, they should be part of the equation not the whole!

Draw a line in the sand about which are vanity metrics, and which are actually meaningful

Brooklyn Zelenka

Product Manager/startup founder

Be honest with them and upfront . Do not wait until it is beyond the deadline to tell them that it will be another week.  They may be talking to investors or senior leaders and promise dates.  Keep people up-to-date.

Community

Paying attention to community managers needs are important they will often see “mob” or “crowd” behaviour and form impressions.  These are invaluable, take time to have coffee/lunch with a community manager every month.  Community Managers may seem trends forming before they pop up on your analytic dashboard, if indeed they ever do.