How I Survived My First Week as A Software DeveloperReflection, Collaboration, and HumilityGregory ‘Grey’ BarkansBlockedUnblockFollowFollowingMay 9Today is exactly one week since I started an internship at a medium-sized software company.
This isn’t the first time that I’ve developed professionally; however, my prior experiences were only in academic, OSS, and freelance settings.
What follows is a reflection about what made my first week successful.
Photo by Venveo on UnsplashTake NotesThe thought of taking notes brings to mind lectures, meetings, and research: A first day of work is not on the list of scenarios.
Yet during a first day, one is bombarded with important information via orientations, tours, and company history.
It’s really a combination of all the above, but with the added caveat that it takes place in a foreign setting.
As a result, it’s easy to feel bogged down from information overload, and helpful facts may not be absorbed.
Therefore, it’s critical to take notes on a first day so that the wealth of new information does not compete for brain space against the overwhelming excitement that will be swirling around.
Beyond the first day, software development — and any profession for that matter — involves planning, learning, and creativity.
With respect to planning, key tasks are arranged by project managers and tracked in digital applications.
But day-to-day tasks are often self-managed, and it’s worthwhile habitually spending two to five minutes writing down the goals of your next work session.
I recommend planning for the current day either immediately after arriving or before leaving on the previous day.
When learning new technologies or engaging in design, it is common to blueprint, sketch, and jot.
But we must go one step further to extract the full value of these activities.
The long-term realization of personal growth occurs from reflecting on these activities.
My mind naturally drifts towards reflection when I catch a moment alone while walking or during my commute.
However, some prefer scheduled “check-ins.
” Either way, it is important to capture the major takeaways of those reflections.
For taking notes, I recommend a basic lined Moleskine or anything that closely approximates one.
However, typing is quicker if you prefer using a highly portable laptop (and especially if the company has given you one).
Regardless of the note-taking device(s), the mechanisms of taking notes are the same:The device(s) should be portable.
(I often carry my Moleskine while on walks — even if on the weekend.
)It is encouraged to write a short entry during or immediately after spontaneous reflections, epiphanies, and intriguing ideas.
Distill your notes to the essentials.
I often find it helpful to use a question/answer dialog with bullet points.
Always title and date your entries in order to capture themes and growth timelines.
Ask QuestionsThis cannot be emphasized enough: Asking questions is a critical part of the ongoing conversation otherwise known as “onboarding.
” Many hold a fear that asking questions leads to negative outcomes such as annoying colleagues or appearing incompetent.
Furthermore, many of us have worked in an environment with hostile co-workers.
If you’ve been put down for asking questions (particularly as a new employee from somebody on a power trip), I will state as matter-of-fact: They are in the wrong (and, in some cases, are just assholes).
A healthy work environment requires collaboration and teamwork, which can only be accomplished if each member feels confident engaging in discussion.
Building a rapport with co-workers takes time and is exponentially harder the longer one delays initial contact.
My office is shared between teams working on separate projects and includes people with various roles.
I’m a full-stack developer on a dedicated project, yet I sit near a database administrator that mainly oversees a different set of projects.
Still, I made the effort to introduce myself to them and asked if they could give me a brief on their work.
As a result, we now hold casual conversation whenever we pass each other.
I also feel confident approaching them down the line if any of my tasks depend upon or could benefit from their direction.
A critical set of questions you should immediately address are those regarding setup of your work environment.
By asking the right questions, I not only got my laptop upgraded, but my co-worker found that the README for setting up the dev environment was outdated.
If I had instead rolled up my sleeves and put my head down for a week, merely trying to get the project running on my local machine, I’d look fairly incompetent upon revealing that I hadn’t accomplished anything.
Instead, I managed to submit a PR on the very first day!.So much for asking questions equating to incompetency.
Be Open to Review and Constructive CriticismMy second PR at work was ~300 lines and took three days before it was merged.
The reason it took so long is that it got reviewed five times.
That’s five whole times I confidently pushed code after thorough inspection only to receive multiple comments, suggestions, and highlights.
Granted, some of these comments were modifications to requirements (this is an agile shop) — fair enough, the logic was updated accordingly.
But more than a handful of times, the comments left by my reviewer were ways I could improve my code.
This experience of constructive criticism and collaborative algorithm design has been one of the most rewarding in my career to date.
For those that take a little too much pride in their code, it is critical to remember that software is built collaboratively.
Furthermore, each developer brings unique insights from which everyone can benefit.
In software engineering, we use well-defined tools and adhere to standards and protocols to the best of our ability.
Despite these efforts, there is always a mix of ad hoc solutions and heuristics.
When facing review, the code itself (not you) and the software as a whole are being evaluated against all of these, as well as internal standards to which you may not have been privy.
Therefore, you can still hold pride — but that pride is for your role as part of a team and the quality software you build together.
Lastly, code is a universal language for developers.
Requirements, mocks, and design discussions have obvious use but do not always readily translate to code.
Once code is written, the team can zoom out and understand each other’s perspectives and challenges.
For this reason, most development cycles are very iterative; often, requirements are not complete until some of the logic is first attempted.
Then, they are refined.
Review then becomes a natural part of the process.
Indeed, in the article “GitHub Flow,” Scott Chacon [1] wrote about this iterative nature of PRs stating: “We use [pull requests] to review the code long before we actually want to merge it.
” Thus review is a critical aspect of the cycle and something to openly embrace.
Ultimately, it’s a conversation held in a domain-specific language.
Beginning a new job is equally exciting and challenging — there are many new people and internal facts to engage with.
In the context of joining a software team, I believe that self-reflection, collaboration, and learning from colleagues form the major basis for not only getting started in the right direction, but for also maintaining it long-term.
After all, we should strive to be lifelong learners of not just others, but also of ourselves.
References[1] S.
Chacon, “GitHub Flow,” 31 August 2011.
[Online].
Available: https://scottchacon.
com/2011/08/31/github-flow.
html.
[Accessed 8 May 2019].
.. More details