What does your job title mean?

Could you summarize what you do on a day-to-day basis for newbies or intermediates still trying to figure out their career paths?

Comments (8)

Bolaji Ayodeji's photo

I'll go first.

I work in Developer Relations at Hashnode (The best company in the world right now 😌)

I build relationships with the super awesome developers using our platform(s) and create a thriving ecosystem for our own community of developers. My daily job includes but not limited to:

  • Learning
  • Sharing knowledge
  • Reading
  • Making sure that users are happy with our products
  • Inhouse strategies to make our users happier
  • Getting feedback from users and relating it to the engineering team
  • Proposing new features based on user feedbacks
  • All-round writing
  • Speaking at and attending developer events
  • Organizing IRL meetups with my team and volunteers
  • Standups and Syncs with my team
  • Creating and contributing to Open Source
  • Writing JavaScript code and building bots
  • Interviewing amazing women-in-tech on She Inspires series

and more...

Francisco Quintero's photo

Software Engineer

Wow, your job is really cool. Is Developer Relations different to Developer Advocate?

Sandeep Panda's photo

Hello all! I am the co-founder of Hashnode. I am responsible for all the technical aspects. My job includes, but not limited to:

  • Working with the engineering team to ship features, bug fixes and other updates.
  • Reviewing PRs
  • Maintaining Hashnode infrastructure and ensuring the reliability
  • Managing deployments (and making sure not to do this on Fridays 😉)
  • Meeting investors and keeping them in the loop
  • Brainstorm ideas and think of ways to make Hashnode better

I have no hobbies other than writing code, writing about code and thinking of how to make Hashnode more friendly, inclusive and better.

Francisco Quintero's photo

Software Engineer

Managing deployments (and making sure not to do this on Fridays 😉)

When in doubt visit shouldideploy.today 😆

Todd's photo

Mine is Technical Lead - Software Security

I am the lead engineer of a product/application security team.

What this translates into is:

  • Helping craft goals for the team and checking in to make sure that we are making progress towards those goals

  • Making sure each team member is challenged, stimulated, and that their skillsets are being used to benefit the team/company

  • I am often the "spokesperson" for the team in meetings with upper management and other teams/departments. I've worked with people ranging from PR to marketing to sales to engineering to legal to IT on problems affecting application/product security. This is definitely something that I learned when I got into security engineering - communication skills are even more important than other types of engineering. A good example of how this may play out is say a customer service manager uses some third party software to interact with users, and that software has a security vulnerability but is hosted on our domain... It could impact our users even though it's not our software, so I have to work with this sales manager to get contacts at the third party company and work with their security team or engineers to see that the issue is fixed!

  • Managing our bug bounty program - imagine a GitHub Issues section where all of the submissions are security vulnerabilities from hackers/researchers. My team takes these, checks to see if they are true (validation), writes an exploit to prove the vulnerability exists, and then works with the engineering team to remediate the vulnerability in a patch.

  • Working with Product and Engineering teams to advance the security posture of the software and hardware products. Meaning, for example, if this year we are using TLS 1.0, next year we want to upgrade to TLS 1.2, etc... Being an advocate and pushing these types of things along. Developers are often focused on just getting the product working properly, whereas we're focused on getting it properly secured.

==========================================================

The above uses probably about 50% of my work time... THe other 50% of my work time is spent on technical tasks. I also spend a lot of my free time on technical tasks at home so I would still say that the majority of my overall time is spent on technical stuff, which I love too! So let's get to those:

  • I work with code most days of the week lots of different code. In one given day, I may be writing a C program, modifying someone else's python script to add some features, writing an exploit for a vulnerability in JavaScript for our web code, reverse engineering or writing some assembly language code, reverse engineering some C# code, and sometimes even more! In a single day some days!
  • I work on tasks such as reviewing application architecture to find security weak points (threat modeling), consulting with engineering managers and leads about weak areas of their application and seeing what types of attacks I can pull off, writing code obfuscation algorithms, suggesting specific ciphers for encryption, attacking applications from a "bad guy" perspective (we call this black box testing), reviewing source code (white box testing), and more.
  • Our team also provides training to software developers so for example, we may teach a 1 hour training course on how to prevent cross-site scripting, how to secure API keys and tokens, how a type conversion vulnerability can be used to exploit a system, and etc...
  • Our team has to work with 7 different platforms/domains: macOS, Windows, Linux, firmware, Android, web/cloud, and iOS. This is one of the most exciting, challenging, and fun parts of the job. Most of the development teams are focused on one main platform such as the iOS team or Android team. We have to be skilled in all platforms.

As you can see, the job involves a lot of different hats and it can be hectic at times, but very rewarding and fun as well. Members of this team trade having to deal with security emergencies and switch subjects frequently for having more research time when things are slower. This is a bit different from typical software development which is focused on getting a specific feature released or a specific product out.

Gergely Polonkai's photo

Um… wich one?

I work for Benchmark.games, a company providing gamified assessments (i mean, actual video games, not just some HR process where you collect badges to qualify) to select potentially great candidates. Depending on the time of day and other circumstances iʼm one of the following:

As a backend developer my daily tasks include creating new features in our backend (mostly an API service, but there are some legacy, server generated views, too) and fixing bugs.

As a software engineer i try to plan said features as detailed as possible so me and other developers can start working on it.

As a systems engineer i plan how components of our system will work together. This includes everything between what components we will actually use to and how they access each other (network connections, encryption, etc.)

As a CTO i make decisions on what technology to bring in, what service providers to get a deal with, and any other high level technical mumbo-jumbo you can imagine.

Until our team is so small (we have 13 employees, including external workforce mostly in the sales division) this will remain. As i donʼt want to give up coding, i think i will stay with the software/systems architect title, with some tasks in the actual coding.

I currently like acting as a CTO, but iʼm still unsure if i could do it at a larger scale.

Francisco Quintero's photo

I'm a Software Engineer at ideaware.

My daily job consists of:

  • Building features in Ruby on Rails REST APIs projects
  • Figure out with frontend developer best way to solve/implement something
  • Discuss with PM issues, requests, bugs, times, tasks, etc
  • Guide product demos whenever there are features our client needs to validate
  • Share awesome or useful stuff I found on the internet about software development as a whole :D

Sometimes I also:

  • Write posts for the company blog
  • Help HR in recruiting(interviewing and technical challenges) Ruby on Rails developers
Eric O. Jonathan's photo

A job title is for me is just a rough description of what I could and obligated to do at this very moment. On one hand, I couldn't say that I have mastered all the skills needed to do for that describes for the job title. On the other, for the very least, the required jobs can be done and were done satisfactorily, even if there are always new skills to be acquired along the way.

Moreover, having had a number of years of experiences in different type of IT jobs, both in technical and managerial jobs, I have to say that the job title is simply that I could fulfill the required work that the job title describes and it does not reflect all my job skills that I have accumulated over the years, be it technical or managerial. Thus, a job title only defines me at the current work that I am obligated to do and this can be a full stack software developer at the moment but it could be entirely different on the next one.

Working as a Full Stack Software Developer

My day to day work is supporting a custom Enterprise Software Resource system (ERP) that runs on ASP classic for its legacy system and also ASP .NET. Mostly my job deals with bugs but occasionally deals with improvements with new features that the users might want to use.

The system we use is Azure Devops in the form of tickets or cards. From the tickets submitted from users and the software manager, we then start to piece together what is needed, the types of functions need to be created or modified.

Since we use a GIT repository system, we fork the application from the main branch and we create a local branch that we can do and test. Once it's done, we push it to our own branch for the manager, who also acts as the tester, to test the work and validate if it's a passing test or a failing test. Once it is approved that we merge the work to the main branch where the software manager then deploys it to production.