DEV Community: Jacob Herper

A day in the life of a Software Engineer at Holland & Barrett

Jacob Herper — Fri, 07 May 2021 09:02:01 +0000

A lot has changed for most tech companies over the last year. While we were all working from an office at least 3-4 days per week before the pandemic hit in early 2020, almost everybody works remotely now. At Holland & Barrett, we are in the lucky position to help people with their wellbeing during the pandemic. Therefore, our stores remained open throughout all the lockdowns, but we also saw a significantly increased demand in our digital platform. This is one of the main reasons our engineering team has grown from a small part of the organisation to over 150 people in less than one year - and we continue to grow beyond our wildest beliefs just one short year ago. This article should give you a rough idea of what a typical day in a software engineer's life for the UK's leading health and wellness retailer looks like.

I usually start my workday at 8:00 am with a fresh cup of tea by opening up my email client to check on any issues that might have happened overnight or see if any meetings have been scheduled after I left work at 4:30 pm the day before. Next, I sign in to Jira to check the progress of the current sprint and see if any of my colleagues' tickets are ready for code review, at which point I open up Gitlab to look at open Pull Requests (or Merge Requests, how Gitlab calls them) and see if any of them require my attention. Furthermore, I connect to the VPN at this point to access any of our internal APIs and run code without interruption on my local machine. I typically spend around an hour on code reviews for my peers to ensure all our tickets move along smoothly.

Now is a great time to catch up on Slack conversations that might have happened after I left the day before since our team works flexible hours, and while my workday ends at 4:30 pm, other colleagues work until six or even later.

At 10 am, it's time for our daily standup where our cross-functional squad goes over what we did the day before, what we are planning to work on today and whether there are any issues or blockers that require a colleague to resolve before we can move forward. Standups are relatively quick in our team, and by 10:15 am, I usually find time to focus on actual development work. More often than not, the mornings are free of meetings, which allows us to either work on tickets alone or collaborate with a colleague to do some pair programming or discuss an issue we ran into in our code.

With a short break in between to stretch my legs and grab another beverage, this takes me to around 1 pm – lunchtime!

One of the great benefits of working remotely full-time is sharing my lunchtime with my wife and daughter and cooking a fresh meal every day and depending on how long it takes me to cook, I can either go for a quick walk with my daughter or find some time to play with her.

At 2 pm it's time to get back to work, and if the day is free of meetings, I will try to wrap up my work from the morning, look at my implementation again and see what I can improve, add more tests or pick up a new ticket from the backlog. Most days, there will be a meeting or two in the afternoon, and I try to spend a few minutes before to prepare myself for the discussion and pour myself another cup of tea.

Towards the end of my workday, I make sure that all my changes are committed and pushed, ready for the next morning. At 4:30 pm, I say goodbye to the team on Slack, close my laptop and disconnect from work.

What Open AI's GPT-3 means for developer jobs

Jacob Herper — Wed, 29 Jul 2020 08:25:53 +0000

If you have been on Twitter, or anywhere on the internet for that matter, over the last few weeks, you will have come across the cryptic abbreviation "GPT-3", which stands for "Generative Pre-Training (of language models)", version 3. While its predecessors GPT and GPT-2 were far less effective and therefore less impressive, version 3 has caught on in the development world. You might have seen examples, where GPT-3 is trained to generate React components or SQL queries just by giving it text input. Developers fear for their jobs, but should they?

Sharif Shameem

@sharifshameem

Wow.

I built a React dice component with GPT-3.

This feels far more fun than writing JSX.

11:07 AM - 19 Jul 2020

103 607

While the examples mentioned above are impressive, the reality is, that there is a difference between these presentations and the reality of using an AI algorithm to code complex applications. AI models, such as GPT-3, tend to misrepresent certain user input and might, therefore, go in a completely wrong direction very quickly.

Product owners will replace developers with AI

While this looks reasonable on the surface, it becomes clear that a product owner or project manager will hardly be capable of using a tool like GPT-3 to replace developers. It is difficult for a developer at times to understand and work through product requirements set by non-technical product owners, so how should an AI algorithm decrypt these requirements?

If you look closely at the examples given by Open AI and the first public beta users you will notice, that the input needs to be written in a "sterile" syntax, that is easy for a machine to understand. It reminds me personally of the Gherkin syntax used for BDD tests in certain environments. To give GPT-3 instructions it understands and executes correctly, you need to be a developer, or at least have a certain level of coding experience, to write these instructions. Therefore, it becomes just a layer of abstraction on top of programming languages. A certain level of standardisation would be required to make the output predictable, looking at the way GPT-3 appears to work at the moment.

Conclusion

GPT-3 is a fancy new interface to generate code (and of course other output, I am just focusing on the implications on developers here, so not going into depth on different use cases). In my opinion, it will not replace developers anytime soon. Instead, it will become another tool we can use to generate code.

A great use case for GPT-3 would be the generation of a lot of the boilerplate code we have to write on a daily basis, where snippets and frameworks are not convenient because a more custom approach is required. Instead of fearing for our jobs, we should think of ways we can use a technology like GPT-3 to our advantage.

Lastly, product owners who dabble with GPT-3 will soon realise that it is not a replacement for developers, just like code-free solutions such as Webflow, Wix and so on won't replace developers for companies with advanced requirements. My conclusion is, therefore, that our jobs are secure for the foreseeable future.

How to get hired as a developer or software engineer in 2020

Jacob Herper — Tue, 28 Jul 2020 11:52:30 +0000

The world has been put on hold for many of us through this pandemic. A lot of companies have been furloughing developers, and others have made parts of their engineering staff redundant. With that much talent being available, how can you stand out to recruiters and get hired during or right after the global pandemic?

I have been a senior front-end engineer at one of the largest publishers in the UK for the past year and recently decided to move on, after my employer announced, that it would make a quarter of its employees redundant by the end of July. And while my role, in particular, wasn't at risk, I still decided to move on, despite everything going on in the world. It took me exactly one week to get hired by another company with a more exciting tech stack, and with a salary increase. How did I do it? By standing out to recruiters. Follow my lead and get hired without having to jump through hoops.

Share your code

I know it is a bit uncomfortable at first to have potential employers look at your unfinished, broken and buggy code on Github. A lot of these side projects you once started working on but never finished, do not even follow best practices, so why would you present this to anyone - let alone a recruiter or hiring manager?

A Github repo is an excellent mirror of your personal development. If you have your repositories public, it can show how you improved over the last X amount of years. Nobody expects every code snippet to be perfect, but as long as the general structure of your code makes sense and it is well commented, this shows a potential employer that you know what you're doing. If you have some repositories from 3 years ago and others from last week, it also allows them to see how far you have come in the last few years and that you are willing and capable of learning new skills.

For more senior roles, it might also be useful to show your activity overview on Github. This tells a potential employer, what you have been doing (commits vs. pull requests vs. issues vs. code reviews) in previous roles and how active you are.

Other platforms

Besides Github, there are a ton of other platforms that are worth keeping up-to-date. Publish code snippets on CodePen or CodeSandbox. It is useful to share code snippets on these platforms because they do not have to represent an entire project, and they don't have to be as polished as a Github repo might.

Ask and answer questions on Stack Overflow. There are a lot of recruiters browsing around for talent on Stack Overflow, so make sure to have your profile up-to-date there and try to be a helpful community member to stand out. I have to admit that I am personally not great at that, so I have never been hired through Stack Overflow, but it is certainly an option.

Try to stand out to recruiters on LinkedIn. While most of us developers don't really care all that much about LinkedIn, it is where recruiters are, so make sure your profile is up-to-date and in great shape. I get contacted by 3-5 recruiters a day on LinkedIn alone.

I have written an entire article on how to stand out on LinkedIn:

How to stand out as a software engineer or developer on LinkedIn

Jacob Herper ・ Jul 28 '20

#career #linkedin #jobsearch

Write about problems you solve

Admittedly, I am not great at this (which is one reason I am writing this very article, to convince myself that I should start blogging more regularly about problems I solve). However, writing down how you solved a specific problem you came across in your work is not only beneficial for others, but also for your own career progression. Hiring managers will find your articles and the simple fact that you learned in public shows that you can explain technical solutions to the team around you, which makes you a much more valuable asset to an employer.

If you are more comfortable recording videos or podcasts, this is of course also a great way to share content with the world, so it doesn't always have to be written content.

Photo by Scott Graham

How to stand out as a software engineer or developer on LinkedIn

Jacob Herper — Tue, 28 Jul 2020 09:01:24 +0000

Most of us developers like to hang out on Github, Twitter and Medium. LinkedIn becomes an afterthought that most of us don't really pay attention to. However, it is where recruiters are, so having a profile that stands out of the crowd is especially important.

In this article, I explain to you what I have been doing to my LinkedIn profile to get contacted by 3-5 recruiters every single day!

About section

Have an exciting and engaging paragraph or two explaining what your passion is, and which technologies you have experience with. Here is mine:

I am a passionate Software Engineer, specialised in front-end development using React and TypeScript. As an advocate for web performance and accessibility and an evangelist for the Jamstack, I create amazing web applications to make the internet a better place.

This is short and sweet; it tells recruiters precisely what I do and how the team they are hiring for could benefit from me.

Experience section

List all your relevant experience and provide short bullet points with the work you were doing and mention the technologies you worked with. Some great points might be:

Led a team of 5 front-end engineers
Developed web applications using TypeScript, React, GraphQL and Sass
Increased site traffic by 40%
Improved Jest test coverage by 20%

Education and Licenses & Certificates

I personally never went to university. Straight out of college I founded my own agency, and I was my own boss for the first seven years of my career, and yet, I have been hired as a senior software engineer and have been contacted by recruiters from Facebook and Google. This proves that education is not everything. It does, however, help if you have some certificates that you can list on your LinkedIn profile. The one that I found sparked most interest for me is the CS50 certificate from Harvard University. It is a free computer science course you can take online in about 8-12 weeks that teaches many fundamentals that are great for engineers of all levels.

Other certificates you can list are those you get from sites like Pluralsight, Udemy or LinkedIn Learning.

Volunteer Experience

I have been a mentor on Coding Coach for a while, where I help more junior developers achieve their goals. While this is a relatively small amount of effort, it lead to many questions during interviews I have had and showed the interviewer my interpersonal skills.

Other volunteering experience you can add here is Open Source experience, for example, if you regularly contribute to a specific project on Github, add it to your LinkedIn profile as volunteer experience.

Skills

While most recruiters say they do not look at the skills and endorsements part on a LinkedIn profile, I found that a lot of endorsements spark interest as well. I have my top skills all at 99+ endorsements. I would also recommend taking the skill quizzes you can take on LinkedIn for free - they are great to show that you actually possess those skills and don't just put them there as fancy buzz words.

How to get 99+ endorsements? Ask people you worked with, even if you did not work with them directly. I asked a lot of my former colleagues, clients and friends to endorse me on LinkedIn in return for endorsements on their skills.

Recommendation

Recommendations are generally harder to get than endorsements because your (former) co-workers have to actually spend some time writing a couple of paragraphs about you. In my opinion, it is worth convincing co-workers to write recommendations for you, as those genuinely give a more in-depth insight into you as a co-worker. I would try to get to around ten recommendations to stand out of the crowd.

If you follow all the above, you are on the right track to becoming a LinkedIn all-star!

Photo by Greg Bulla