Reality of Software Development

so the reality for most of us in software engineering is that we aren't 25 year old models living in the Bay Area working two hours a day and making three hundred thousand dollars a year what I want to do is paint a more realistic picture of what the day-to-day of an engineer looks like at most small to medium-sized businesses the biggest influence on your day today as an engineer is the management style of your company most of the orgs I've worked at were agile or scrum based this means is that we work in two-week blocks these are called Sprints with the expectation that we try to finish off all our work within that time agile teams are infamously known for having a lot of meetings there are just a few of them that are very important for developers the first one is Sprint planning before we start every block of work we plan out what kind of work we're going to do within that period of time and this is very important for Developers for two reasons one is that you can see at a high level what the most important tickets are and if you're edging for a promotion you can go try and pick up that piece of work another one is that you can see what kind of Technologies the Company's trying to introduce in the future and you can Usher yourself in to working with those and sort of learning on the job another meeting is stand-ups and these are mostly held for Daily Progress on your work these are great sessions to communicate to the rest of the team if you're blocked or if you have any questions finally another very important meeting is the estimation session developers basically make a rough guesstimate on the amount of effort and time that it takes to complete a task to make these estimations a lot of companies use t-shirt sizing like this is a small piece of work medium piece of work or large piece of work or they use a numbering system and they're normally presented by a product manager or business analyst or if the work's extremely technical say refactoring some old code it's done by a developer or a tech lead so that's scope of work I referred to earlier is normally known as a ticket or a project and it's hosted on a project management software sometimes it can be atlassian Suite so that's jira Confluence and bitbucket or it could be on GitHub or gitlab now that we're done planning what we're going to do estimating what we're going to do we finally get into the good stuff which is development and as an engineer you're probably going to get a few of the following tickets so it's going to be a bug from customer support maybe a new feature an internal tooling and if you're lucky and your company is very nice you'll get to refactor some tech debt now while you're in development you're actually going to spend a lot of time researching before you even code so that means reading up on the documentation in the ticket sifting through the code or if you're really new to the industry and this happened to me a lot in the beginning you're going to spend a lot of time getting your environment up now that your environment's up you understand the problem you have a working solution in your head you want to go and get check out a new branch and start coding so sometimes when you're coding it's very natural to be stuck or blocked by something that you don't really understand and if you have a really good team culture you can reach out to your teammates and they can hop on a call with you or come to your desk and you guys can work together this is called pair programming and it's very popular in the industry because it's a really good way to build teamwork and actually learn a lot from your seniors and share knowledge it's a fantastic practice and it's one of the ways I've grown the most as a developer so you fix the bug or you've built the feature you've written your tests you can now push your code and get it reviewed comments might start rolling in from other Engineers OR tech leads and these are mostly about things like naming conventions the complexity of the code you've written whether or not you're using best practices whether or not you just rewrote a bit of code and you could actually use it from somewhere else in the repo once code review is done or while code reviews happening a member of your quality assurance team will pick up your ticket and test that feature disgusting it's at this stage if you have any bugs you're gonna have to go and fix it and get a code reviewed again restarting the whole process so for new developers I highly recommend test out the QA tests yourself and make sure that you're not going back and forth with them because it can get really frustrating another important aspect of the job that's not really talked about is documentation this can be Internal Documentation so why a specific library or package was used or why a code base is designed the way it is or it could be external documentation to sysadmins or Cloud Engineers on how to get the system them up and running on their environments to sum up all the parts your average day would probably look like a few meetings here and there maybe stand up or estimation maybe a pair programming session or a design documentation brainstorming session otherwise you should have full autonomy and control of what you're doing with your time so yeah that pretty much wraps up this video thank you for your time like And subscribe if this brought any value and I'll see you in the next one

Channel: bigboxSWE

Views: 605,381

Keywords:

Id: VW0Sn_ZKumg

Length: 5min 7sec (307 seconds)

Published: Tue Mar 14 2023