Skip to main content
5 answers
5
Asked 813 views

What is a day to day life like as a software engineer?

#software-engineering

+25 Karma if successful
From: You
To: Friend
Subject: Career question for you

5

5 answers


0
Updated
Share a link to this answer
Share a link to this answer

Scott’s Answer

An average day for a non-lead SE would generally be broken up into:

1) Team/stakeholder sync-up. If using scrum, it will be the daily scrum (standup) meeting and should be relatively short. We're also starting to see more SAFe (Scaled Agile Framework) being employed for enterprise development efforts.

2) Additional contacts/meetings with stakeholders/users as needed to elicit or clarify requirements / user stories. Work is divided into larger epochs and then broken down into smaller tasks that reflect tickets in an automated ticketing system like Jira or TFS. The product folks will generally set up the epochs, but SEs execute or participate with the task breakdown.

3) Design efforts at the level you're working. This is where all the software patterns you're learning will be employed. "No design" is not-recommended unless it's very simple. Too much design is a waste because you will naturally adapt/tweak as you implement. Many times, design may be collaborative efforts with other SEs and/or architects depending upon the level of design.

4) Implementation (i.e., coding).

5) Check-ins (can happen anytime you're ready). This usually invokes a continuous integration pipeline / processes that compiles / preps your code along with the rest of the team's check-ins. Most important is that the unit / integration tests are automatically run. "Breaking the build" most of the time means that one or more tests failed. Some sites have manually code reviews / walkthroughs or automated code analysis tools or a combination of both. More algorithmically complex code should be manually reviewed.

6) Update the status of tickets that have changed to inform team / users what has been completed. This is critical because other people may be dependent upon your work being completed first or visa-versa.

* Now here's the good news about being an SE. Each day can present new challenges (and rewards), and periodically the programming world is turned 90 degrees because of a new breakthrough. Not much repetition and boredom for motivated SEs! If this sounds like fun, along with making a really good wage, you're looking at the right profession! ;)



0
0
Updated
Share a link to this answer
Share a link to this answer

Heghine’s Answer

My day as a Software Engineer in a team working in a sprint, starts with a stand-up meeting, where you tell to the team what you have accomplished yesterday and what you're going to work on today. Basically, you're working on the necessary task to accomplish the goal of that sprint. Then, most of the day I spent on writing the necessary code for that task, testing it and sending it for review to my team members.
Some part of the day is spent on meetings to discuss some blockers or future work.
0
0
Updated
Share a link to this answer
Share a link to this answer

James Constantine’s Answer

Hello Edwin,

Just to clarify, artificial intelligence won't replace us as programmers, nor will it interfere in areas like religion, politics, law enforcement, medical decisions, and court verdicts.

Absolutely, I'd be delighted to walk you through a day in the life of a software engineer! Keep in mind that the daily routine of a software engineer can differ significantly based on their specific role, the industry they're in, and the company culture. However, I can give you a general idea of what a typical day might entail.

Setting Goals and Prioritizing

A software engineer's day often starts with a review of their task list, followed by prioritizing their work. This is usually based on project deadlines, the potential impact of the tasks, and their complexity. This stage often involves team discussions to understand the requirements better, explore potential solutions, and estimate the time required for each task.

Designing and Coding

Once the priorities are established, a significant part of the day is spent writing and testing code. This could involve creating new software features, resolving bugs, or enhancing the performance of existing code. Depending on the project, this could be a solo task or a collaborative effort with team members.

Teamwork and Communication

Software engineers frequently collaborate with other teams, such as product management, design, and quality assurance. Regular meetings are held to discuss project progress, tackle issues, and synchronize efforts. Clear and effective communication is key to ensuring everyone is aligned and working towards the same objectives.

Continuous Learning and Skill Development

Keeping pace with the latest technologies and industry best practices is a crucial part of a software engineer's role. This could mean attending conferences, enrolling in online courses, reading industry-related publications, or engaging in company training programs. By constantly learning and enhancing their skills, software engineers can stay ahead in this fast-paced field.

Maintaining Work-Life Balance

A healthy work-life balance is key to a software engineer's long-term success. This includes setting work boundaries, taking regular breaks, and prioritizing personal wellbeing activities outside of work. By maintaining a balanced lifestyle and taking care of their physical and mental health, software engineers can prevent burnout and sustain a successful career over time.

May God bless you!
James Constantine Frangos.
0
0
Updated
Share a link to this answer
Share a link to this answer

David’s Answer

Software engineers at different level (e.g. associate, junior, senior, or higher) have different experience in different teams/companies. Your question is also my question during interview, while I asked my interviewer what is it like for their day-to-day life.

While I can't speak for others, my day-to-day life as a senior software engineer is to clear any blockers (e.g. tasks may not be clear or it may depend on another team or information in order to proceed), to meet with other teams to sort out the requirements and timeline, to mentor through code/design review, etc. I don't code as much as I used to, unless it's for my own experiment / project. To simply put, my job is to help the team to move forward in order to deliver the committed goals on time.
0
0
Updated
Share a link to this answer
Share a link to this answer

Chris’s Answer

Hi Edwin -- I'll give you a slightly different perspective. I started my technology career writing code and doing heads down development. Over time, I realized that I was better talking about the code and development than I was writing the code. This lead me to spend more time gathering and translating requirements for our developers. Over time I transitioned into more of an architect (helping define the overall systems operations) and team lead. Then I lead professional services team that wrote code and focused on scoping and estimating the work. Ultimately, I then transitioned into selling software. I'm 20 years into my technology career and now haven't written code (in a professional capacity) in the last 4 years. However, I still leverage what I learned everyday to give me credibility and confidence with the people I work with (I work for a large enterprise software company). My days are now very dynamic and involve collaboration with our partners who work to sell and implement our software. I focus on strategy and partnerships.

It's important to recognize that choosing a path doesn't have to feel like you are completely locked in to only doing that for the rest of your life. I really thought I wanted to be a heads down developer, as I loved creating things that didn't previously exist while solving real business problems. Now, I love helping bringing together really smart organizations to solve really big problems for our mutual clients.
0