Post by Rakesh Singarapu:
This article is originally from Nadia Odunayo’s blog, Starting up, up and away… I highly recommend her blog and especially this article, posted below with her permission, to anyone starting their journey as a junior developer. Enjoy!
I’ve been working at Pivotal Labs as a software engineer for six months now. Before that I was studying at Makers Academy, a twelve-week bootcamp in software development. Not long before that, I was studying Philosophy, Politics, and Economics at university, on my way into a corporate finance career.
I haven’t been in the coding world for very long at all.
I love my job but it has not been easy. We pair program 8 hours a day. This means that I’ve been in the fortunate position of being able to work on complex projects with languages and technologies that I’ve never used before and I am learning vast amounts. However, for 8 hours a day, every day, I’m constantly reminded of my inexperience. I felt a pressure to improve upon my technical skills and be as valuable a team member as I could be sooner rather than later. The pressure stemmed from feeling like I had to do this if I wanted to keep my job, as well as being someone that always wanted to perform at the highest level that I am capable of.
Instead of worrying about it, I decided to proactively work on it. There are certainly steps that you can take that will give you confidence that you are delivering value to your team no matter your perceived level relative to your teammates. The guidelines below are a mixture of approaches that I have tried and advice from some people that I am very lucky to have around me. I hope that you will find at least one thing to take away from them.
Whilst the points are framed in a technical context, I think that those in any industry can find helpful pieces of advice here.
The first thing is not to be embarrassed about your current level.
Admit to yourself how little you know and celebrate in that ignorance. You got your job not because you know it all, but because you’ve got the ability to reason about problems and to think critically. You have got the potential to tackle complicated issues. Get excited by the potential opportunities open to you once you’ve got your mindset straight: you have nothing to apologise for, but everything to explore.
You will never learn it all and you will never get close to learning it all, and being comfortable with this fact is a big part of your mental preparation.
Communicate with your team about where you’re at
Start by being upfront to those that you’re working with about where you feel you’re at, what you’re struggling with, and what you want to know more about. Be ready to listen and keen to learn.
It doesn’t matter how long you’ve already been working with your teammates. It’s never too late to say: ‘Hey, you know what? I’m really not getting this. Can we take some time out where you break this down for me, please?”
Some months ago, I was rolled onto a client project that had been going on for months. The client developers just assumed I was around the same age, with experience from previous programming jobs or projects. Nothing explicit was ever said that gave me an opportunity to clarify these misconceptions. However, what I didn’t realise was a personal pressure that I began to place upon myself to perform to a higher standard than my actual experience allowed.
There was a moment when I became acutely aware of this unnecessary pressure that I was placing upon on myself and after discussing the matter with a colleague at Pivotal, I took the following approach: every morning, after I sat down with my pair, I would say “Just so you know, I’m very new to all of this. I’m actually struggling to make sense of how this app is working, so if you could bear with me whilst I piece it together, that’d be great. It’d also be very helpful for my progress if you let me take control of the keyboard and give me guidance where necessary.”
The response to this approach was far better than I thought it would be. Not only did my colleagues not mind about my lack of experience, they eagerly shifted into more of a guiding role, patiently explaining things and getting excited when they could see the pieces coming together in my head. Each day, I was able to pick up things more quickly and I was more relaxed, no longer feeling like I had anything to prove.
Being aware that most working environments don’t strictly pair program in the way that Pivotal does, I had a chat with a fellow Makers Academy graduate, Josh Hill, who is a software developer at Global Personals. He had the following to say with regards to non-pairing alternatives to getting the most out of being surrounded by more experienced colleagues:
- Get a senior to support you on each project; be clear about what you hope to get out of their support and talk about your progress with them every day; instigate pairing sessions
- Use a rubber duck to help yourself get a better understanding of what’s going on
- Be proactive and explicit about what you want during code reviews; if you’re leaving a pull request, leave questions in it to attract the attention of more experienced developers to choices that you’re not sure about
Being upfront about how you’re feeling on a project is the first step to freeing your mind from any anxieties that you may have about how you’re performing. You create these pressures when you believe that you should be delivering at a level which you’ve not quite reached. When you accept that you’re at where you’re at, it goes a long way in enabling you to focus on the practical steps you need to reach a higher level and to enjoy the progress that you will inevitably make.
Questions, questions, questions
If you’ve got it in your head that constantly asking questions is found to be annoying, then you’re wrong. As long as you are asking useful questions and paying attention to the answers, this will form part of being a valuable team member.
If something is mentioned that I don’t understand, particularly an acronym I’ve never heard of, I ask what it means. If someone explains how the team is going to approach a problem in a way that makes it sound as if it is trivial but I still don’t understand what it looks like in practice, I ask for the steps to be broken down. When I’ve read something technical the night before that I couldn’t quite grasp, I bring it up during a break the next day and ask for someone to explain it to me.
What I’ve found to be revealing are the number of occasions where the response has been ‘I’m not too sure myself. Let’s look into it together’. My teammates have celebrated my questions sometimes as I may have unveiled a flaw in their plan or uncovered a misconception.
What do I mean by the ‘right’ questions?
- Whenever you don’t understand something, ask for clarification
- When your team has decided to go in one direction, ask why and ask what the alternatives are
- When someone expresses an technical opinion, whether it is related to your codebase or not, ask why they’ve come to their conclusion and what developers who disagree might say
- When you have a suggestion for an approach, ask if it is a valid one; follow up with why or why not
By asking the right questions you will most likely find that you:
- Uncover misconceptions or a lack of knowledge within the team
- Unveil flaws in plans of action
- Open up previously unconsidered methods for tackling a problem
- Learn a lot!
When you’re feeling like you’ve got a lot to catch up on it can be overwhelming figuring out where to start. Try and find a particular area that you can focus on that will be very useful to any team that you find yourself working with.
For example, say I wanted to be the person that could look at the codebase and help with the cleaning up and maintenance of the code and tests, I might:
The idea behind this is that no matter what team you are on, after studying the codebase, you will be able to help write effective tests, make useful abstractions whilst refactoring, and make suggestions on how the team could think about improving the overall structure of the application.
Having a strong command of whatever version control system you use (e.g. git) or a tool specific to your team will always be useful. For example, we use something called BOSH on the Cloud Foundry to install packages on virtual machines and those that know how to use it very well often help the team out of sticky situations .
The other thing to recognise is that you can be an effective team member in a way that is removed from the code. For example, as touched upon earlier, you can always be the one that asks the useful questions and makes your team take the time to think and plan their direction more carefully. I’ve always been praised for my positive attitude and enthusiasm. I used to take this as a negative indication that my code wasn’t the area where my main contribution was stemming from, but having an optimistic eagerness and energy during the work day is incredibly refreshing and inspiring. Having this great attitude and delivering quality code are not mutually exclusive things.
Over the working week, you’ll be exposed to a multitude of concepts and technologies, particularly new ways to use technologies that you’re already familiar with. Whilst you might understand these things as they are being explained to you, I have found that you only really grasp something once you try it out yourself. Therefore, it becomes very useful to find a technical side project that you can work on outside of office hours.
If you want to master a particular framework, start by building a simple app in it before moving on to something more complex. Perhaps you’ve wished that a certain tool or app existed – even if you think it’s too challenging for you, start trying to build it and when you get stuck ask someone for help.
Apart from helping your technical skills, as this blog post discusses, there are many benefits to having a personal project outside of work.
I hope that you’ve seen many ways that you can bring value to a team when you’re the least experienced and may be feeling a lack of confidence.
As pointed out in this post by Alicia Liu: “One of the biggest differences between experienced and novice programmers is that experienced programmers know more things to try.“ I’ve definitely found this to be the case and have had my inexperience highlighted when I struggle to suggest ideas for next steps. The steps I’ve discussed above can go some way in helping you to alleviate this problem:
- Accept that you don’t know much and that you have a long way to go
- Share your inexperience with your colleagues and be keen to learn more
- Continually ask the ‘right’ questions
- Focus in on one thing you want to improve on
- Start a side project
Remember that you have a whole network of people around you that are there to help. Take advantage of this resource where you can. Any great team members will be excited to help you reach the next level of your career.
Again, check out Nadia’s blog, Starting up, up and away!
Since coming back to NYC last week, I’ve fallen ill TWICE and so I ended up sleeping and watching NetFlix a lot in the beginning. A friend from my high school, Robert, reached out for some help on his non-profit organization, RescuingLeftoverCuisine, in the mailing list I subscribe to and I reached out to see if I can help out and get some coding practice in. When I learned more about the program, could you imagine my glee when I learned the codebase is in Ruby and RSpec? I was like
After I cloned the code from Heroku, the first thing I did was try to get the tests running and followed the errors messages until I got the tests green.
The first problem I ran into was not being the original developer and being unable to create a database. I reached out the original developer for help on this as I wasn’t making much progress trying to figure it out on my own. He told me to look in the database.yml file. Lo’ and behold, his credentials were there. I checked my old projects to see if I had a database.yml file and gather some more pieces to this puzzle. I ended up deleting the two lines with his email and password and I got a different error. Progress! …I think. I will run this by him when we meet up.
Databases can now be created and migrated. I ran into some issues, so I did the bin/rake db:drop, create, migrate dance and things started working.
I was finally able to run rspec, and this “Redis” thing was breaking most of the tests. So I investigate and employed my shiny new code-problem-solving skills Makers Academy dug out for me.
I found these helpful articles on openmymind.net: Redis: Zero to Master in 30 minutes | Part 1 | Part 2 |. It turns out Redis is a key-value data store, which can be thought of as a data structure engine, according to openmymind.net. I was also delighted to learn that Redis is the most popular key-value data store and sponsored by Pivotal Software, because Pivotal is a company I also have my eye on applying to! Very cool.
After spending some time to understand Redis and the role it plays in the code, I took a look at the Gemfile. I was happy to see many gems I’ve worked with at Makers Academy in the app as well as a bunch of gems I am completely unfamiliar with. I’m excited to be meeting the original developer soon to tuck a few more gems under my belt!
Realize that it’s nothing but a game, and it’s a game you’re going to win.
I was bullied mercilessly through most of my childhood, and it was very much a gendered type of bullying. I was punished for being a smart girl with strong opinions, while demure, pretty girls were treated like queens. There were so many days that I just wanted to give up and give in and be the girl that everyone else seemed to want me to be. But where would I be now if I had? Probably not working in Silicon Valley. I’d probably still be in that town, surrounded by the people who wanted me to think I wasn’t good enough.
If you’re working as an engineer or in training to be one, you’re a hell of a smart person. You’re one of the most sought-after labor resources in the market. Yes, people are biased to believe that women can’t be as intelligent as men, that thought labor is not for us and we are not for it. You don’t have to believe this, though. You know better. You know that you’ll do great work and get a great job, because you’ll find the places that see the truth of you, which is that you’re amazing.
The people who don’t see it or can’t because they are willfully ignorant of their own biases? They have lost the game and they don’t even know it yet.
Really, the only way to lose the game is to give up. Don’t give up.
‘Raduation Day. I spent much of today putting together our team’s presentation and made about 20 videos of our app before I got the sizing and everything perfect. I am very, very proud of our team’s final project. We totally killed it on our presentation and I wasn’t even this happy with what I’ve done at my college graduation.
Here’s a full video demo of how Bunch works:
It works and everything on Heroku: bunch-us.herokuapp.com Check it out!
We partied ’til late like we Makers do.
I’m now a Junior Ruby/RoR Developer seeking employment!
Thanks. In the meantime, I’ll be
During lunch the day before our graduation, Ali gave us an awesome on How to Kill It After Makers.
He says that the wildly successful people he’s encountered in circumstances similar to ours shared these traits. He broke this traits and tips into two parts: before & during Makers Academy, and post-Makers Academy.
Before & During Makers Academy:
1. WORK ON SMALL, FINISH-ABLE PROJECTS.
Keep the habit of shipping software regularly on GitHub. This can also serve as a constant way of applying newly acquired knowledge. But be sure not to be overly ambitious and let that stop you from shipping. Go from something simple like printing ‘Hello Word’ to making your program do more sophisticated things. Check out Jennifer Dewalt’s 180 websites in 180 days for some inspiration!
2. WRITE REGULARLY AND PUBLISH.
This should be work related and technical. Julia Evans writes 200-300 words a day for her blog: https://jvns.ca/ I guess I’m semi-on-top of this since I’ve been running this blog. I need to try to get more technical though.
3. HAVE VALUABLE IDEAS TO SPEAK ABOUT AT EVENTS AND MEETUPS
Speaking at meetups is a great way to build credibility and <secret tip> the bar for speaking at local meetups usually isn’t that high, but you look like a total expert regardless </secret tip>. It doesn’t need to be something you know extensively about, but anything you can talk about for about 30 minutes would be sufficient.
4. MEET PEOPLE AND CREATE A NETWORK OF PEOPLE WHO HAVE YOUR BACK.
Do this by attending meetups and keeping in touch with people you’ve worked with and staying in the pulse of things so that you don’t miss out on unpublished opportunities.
Getting a Job
1. COLLECT A HUGE LIST OF LEADS.
Just anything under the sun that you would be remotely interested in. Bookmark them and have a huge list. Not many companies advertise junior roles, so just mention it when you are networking to collect leads. Inbound leads and leads through your network are the best.
DO NOT USE RECRUITERS.
I asked Ali about in-house recruiters and they seem to be okay, but having a recruiter or recruitment agency as your main source of leads is like slowly sitting on a very long, thin pole. They are incentivized against your interests and would probably hurt more than help you AND the company you’d like to work for.
2. DECIDE WHAT’S IMPORTANT TO YOU, REALISTICALLY.
Big company vs small company? Big vs small tech team? Go somewhere where there are dev slightly better than you. Think about your learning goals and skills development. As junior-juniors, it’s quite important not to develop nasty habits at companies that don’t know what to do with a junior. But money might be an important factor for some people while other care most about location.
3. SEND OUT CV AND COVER LETTERS.
Be sure to have JUNIOR DEVELOPER SEEKING EMPLOYMENT highly visible on your CV. Show shipped software on GitHub, then education, then maybe nice things other people have said about you if you have two pages. For an American CV, there’s probably only room for the first two things on one page. Cover letters should cover big topics and questions such as how you might add value as a junior or some sort of critical understanding of the company you’re applying for.
4. GET INTERVIEWED.
First there’s fluff, and people are just trying to see if they like you. Then there’s the technical challenge which is usually the majority of what dev interviews are made of. A good way to start is usually to repeat their question back to make sure you understand what it is being asked of you. Ask to clarify assumptions and ideas rather than starting to type code immediately. This behavior is a major red flag. Don’t be afraid to say “I don’t know… but maybe I would look into this/that” or “I don’t know, but could you tell me about it?” If they refuse to tell you about something you don’t know, it’s probably not a stellar company for a junior dev. How can you be expected to know everything after 3 months?
Be prepared to ask them some questions. Some generic starters: What are you working on? What’s the best/worst thing you find about working here? Who do you report to? What’s the culture like?
5. NEGOTIATE SALARY.
Have 3 offers. Ask for £36k. Ask companies to wait a little bit longer for other offers to come in so you can choose the offer you want and 3 is a good number for you to be happy with the choice you made. If you don’t have 3 offers on the table or can’t afford to wait, ask for £36k. This number is for London. But the point here is that companies hiring a junior dev can definitely afford to pay £36k and you need to ask for that number if they don’t offer this to you. Just email them and say you need £36k and don’t make a move (i.e. cave) until they get back to you. It also doesn’t hurt to negotiate because the worst they can say is ‘no’ and you are back to where you started. It’s not like your offer goes away because you asked for more money. And if they say yes to £36k when they initially offered £33k, then a single email made you £3k.
If you find Ali’s advice here as helpful and enlightening as I did, then check out his free e-book that you can download at Happy Bear Software: https://happybearsoftware.com/kickstart-your-developer-career.html
Last day before graduation! Look at our Trello board with everything done!
I’m spending today getting the tests that my automatically appearing input boxes are breaking.
Implementing the functionality wasn’t all too difficult, though I still had some help from Alex, because things never work the way I think they would or should. The functionality was there by the time I left Makers yesterday evening. I first had the new automatically-generated input boxes show up in 100% opacity because I had broken about 6 tests. Not too bad. I just went in and fixed the cucumber tests one by one and it was basically taking out the step that involves clicking a “+” button and going ahead to the “fill in next address” steps.
Then, when I wanted to make new input boxes semi-transparent until they were focused on (to be typed into) before having 100% opacity. I did this by making a ‘waiting’ class for the input box that is ‘waiting’ to be used. The waiting box will have semi-transparency until it is focused on and .removeClass() is used to make it just a regular input box, giving the next automatically-appearing input box the ‘waiting’ class.
Look at how sexy this is! (Address 3 is where the input cursor is currently.) Give it a go at http://bunch-us.herokuapp.com/!
During lunch, we had an amazing talk from Ali on How to Kill It After Makers. It seems he has given this talk to Makers a couple of times and always received great feedback.
Then all the groups had a dress rehearsal of their presentations in front of the junior cohort and other teams. I was pretty happy with our team’s dress rehearsal presentation and I think it can be quite polished by graduation.
Pivotal Labs hosts a series of fantastic tech talks every Wednesday, and I attended one given by Margaret Pagel, Vice President of Sales Marketing at 8th Light, on Improving Communication. Margaret shares with us her advice on being a good communicator from her careers in sales for 15 years. She covered five main points on building a human connection and making people remember us. Her slides were absolutely beautiful, and I learned after the talk that they were all done by a UX craftsman at 8th Light. The images I’ve put in aren’t the slides she presented, but pulled from a similar talk of hers hosted on YouTube.
Have 5 key points for small talk about yourself that is likely to be relatable. For Margaret, she introduces herself as a mother of 3, working for her son at 8th Light, living in Florida but working in Chicago, a widow, a huge Green Bay Packer (football) fan. So she talks about family, work, travel, tragedy, and sports, and these are points that people can resonate with at least one of them and she can use start building the foundation of a connection with. So think about stories that are yours, that you’re comfortable telling, that people might be able to relate to and like you.
Talk about your work and what you do passionately. Know and be able to communicate the value that you can bring clearly. Be able to show you know what your talking about with making recommendations and talking about previous work you’ve done. But building trust and relationship requires patience and takes many small steps over a long time.
As the talk was for predominantly software developers, Margaret talked about how non-technical people might feel, when developers start talking tech. This is important because chances are, clients are non-technical, because otherwise they wouldn’t be hiring software consultants! So talk about and explain technical terms. Make sure that people in the room who are non-technical, and even those who are non-technical, understand what you’re talking about. It might be helpful to practice talking about a subject to a spouse or friend and work out how to get those concepts and ideas drawn out.
Also, speak up when there are problems or confusion. Ask someone to explain back to you what you’ve just said for a confirmation of mutual understanding, so that you can work on bridging any gaps.
Margaret talked about facing problems head on when encountering turmoil or calling somebody to get a problem fixed without letting it fester. If the problem involves not meeting a commitment with a client, be sure to keep them in the loop and have them know what’s going on every step of the way. Admit your mistakes and apologize. Be sure that your actions speak louder than your words.
Make an effort to stay connected to people – calling, asking to meet up face-to-face, taking someone to lunch or breakfast, and remain fresh in people’s minds. Margaret did this by spending time every single month to sit down and wrote a thank you letter to every single client and prospects. She would also include a chocolate bar and send them to everyone and when she would attend conferences, people would ask her she’s ‘the candy lady’, and that’s how remained memorable and fresh on people’s minds.
Good communicators, live it. They live their lives centering around great communication and maintaining these human connections.
Today is our feature freeze. This means no more adding new features and working only on styling and cleaning up code. Our team is right on schedule and we paired on adding some unit tests to up our test coverage and refactoring code where we see fit.
I’ve been trying to get some fancy input boxes since the beginning of the week, and see this as the perfect window to get that in. Basically, when someone goes to the bunch page and starts to enter addresses into the input boxes after the second one, another input box will automatically slide down and be semi-transparent. This would make a much nicer user experience that is sleeker and more impressive!
My team wasn’t so supportive of me trying to add this styling though. Implementing this styling would definitely break a lot of feature tests since the tests ran by clicking a button to add a new input box, and our entire app was dependent on those input boxes working properly. I understood their concerns, but I knew this was the right thing to do and knew that if someone helped me, we could do this and get everything done, with tests passing, with time to spare tomorrow. But my team didn’t seem too interested in working on this, so I would have to do this on my own if I really wanted it. So I asked if I could figure out how to make it work, if they would be cool with it, and the majority said yes, so I have to get crackalackin’!
In the afternoon, I attended one of the fantastic tech talks that Pivotal Labs hosts every Wednesday. This week’s talk was given by Margaret Pagel on Improving Communication.
After lunch, each team did a rough presentation in front of Alex on our final projects for preliminary feedback. Our team got a rough presentation put together and the basic flow of who does what, in what order. Charlotte will introduce our app, I will narrate a demonstration of how Bunch works, Jeremy will talk about the algorithm and backend of the inner-workings of how we churn out our results, Pete will talk about the various technologies and tools involved in building Bunch, and finally Dave will talk about how we can extend and take Bunch further if we had more time.
Noam commented that Team Bunch is the only team he’s observed that’s always working/”looking super serious” and never plays any ping pong. Hmm.. Interesting.
Charlotte and I got the tabs for different venue categories – Top Picks, Food, Coffee, and Drinks – working. The hardest part about doing this is applying the appropriate style to an ‘active’ tab. So what happens if the computer doesn’t know if the ‘cafes’ should be in the ‘cafe’ tab? You get restaurant/cafe/drinks content going under the default ‘Top Picks’ tab.