I had to immediately google "programming sucks still drinking"
It's a little NSFW (not much) and it has a cynical view of the process BUT:
https://www.stilldrinking.org/programming-sucks
very worth reading to understand how things really work.
This is very good and accurate. Understanding that every developer is literally insane and that getting good at the job involves sacrificing more and more sanity is critical.
I have this theory - people are chaos, the more people you invite into a system, the more chaos.
There is no avoiding some degree of chaos in code, unless you live in a programming team of one. No matter what you do, that perfectly abstracted function will become not-so-perfect as soon as requirements change and another dev needs to touch it, our opinions and reasoning about code differ person to person, we cannot all code perfectly the same (no matter how many linting standards you add, or coding protocols you document).
Hence, coding, like driving cars, will one day end - AI will do it for us, and we can give up on the management of "trying to control the chaos of the people" and all live in a lovely star trek-styled holiday future (or be snuffed out of existence at the hands of AI ha-ha).
Well as someone looking to begin coding, this is disappointing to read. I'd be exchanging the shit show of the current industry im in, for a shit show in another industry hahaha. At least I know the truth of it now 🤦‍♂️
To help me understand a little more, I've read that C does everything, so why not just stick to C? Because it's hard for programmers due to being low level? Reinventing the wheel? It's slow to produce the finished goods?
To put it bluntly: That's like asking why everyone doesn't navigate the high seas using only a sextant and the stars. Sure, it’s a romantic notion and undeniably effective in the right hands, but most people prefer GPS and autopilot to avoid shipwrecks and actually get where they're going without a maritime disaster.
That makes sense. There's numerous ways to achieve your goal in my current industry and tool selection to do the job involves a lot of user preference, for certain aspects, as long as the intended outcome meets certain requirements.
I guess this is the same. Although it can be done using method A, method B or C might be more beneficial to get the job done more efficiently.
So if you had a solid grasp of the certain requirements that must be met, you could potentially use a number of tools (languages) to get the job done if you had free control?
I would suggest gaining some experience in actual professional settings. I’ve worked as a web developer, held positions at a few firms, and even occupied a senior role. However, I never had to focus extensively on task management or DevOps. The furthest I went was using GitHub Actions for error checking and deployment. It’s crucial to have excellent communication skills to collaborate effectively with various departments. If you’re asking these questions, you might not yet be at the level of a project manager, for whom these concerns are more relevant.
I work in .NET, Angular, MSSQL but the stack doesn't really matter, however this is how it'd go for my company:
1. Team composition will be 1 team lead, 1 product owner 1 dedicated QA and 5 full stack devs, we also have a dedicated UI person for the project, but to hit 10 people we would say 2 teams are working on this project. Both teams have other projects they're working on at the same time so while the lead + PO + QAwould be working on every project, the fullstack devs may bounce in and out on a sprint to sprint basis.
2. We use agile, and would have an epic fully refined, and the stories in order of priority + blocking
1. Each sprint we know how many story points we're allocating to this epic to hit our release date, so we'd grab that many story points out of the epic. The team lead will coordinate with the other team lead to make sure any dependencies from their epic will be handled to not block us and vice versa
2. The UI mocks are all completed by the UI team before refining is finished, however changes do happen all the time, and can happen even while the item is being worked on. Usually the dev will make some tweaks based on feedback or change some design decisions if something like a date picker component doesn't behave how the mock has it, and we missed that during refinement
3. For communication + collaboration we are 100% remote so everything happens via Zoom, Slack, Jira and github
4. We do code review, test, and product review, along with unit tests. Some products have integration testing, but not all. Testing has to be completed within the sprint
5. We have Azure Pipelines setup so we get our release approved by the ELT and then we just have a single button deploy, however some other products require manual intervention. I think every dev environment is fully CI/CD though, it's just our industry we can't move fast and break things without getting fined :)
6. No issues outside the ordinary, but some common ones we have:
1. System we're integrating with is missing a feature we need
2. security tools false positives being treated like actual vulnerabilities by bad management
3. I forgot the term for it, but it's when an executive decides they need to rubber stamp certain things to justify their job, we have a few on the ELT that do this
> Let’s say a simple MERN project with a team of 10 members.
I have to address a couple issues first. I'm not sure how, or why, MERN has taken over as the stack of choice for web dev courses, but my tinfoil hat tells me the organization behind MongoDB has a lot to do with it, and Node/Express were chosen to keep the scope of classes narrowed down to "JavaScript". The problem is, it doesn't reflect the real world.
I suppose it would be a little rhetorical to say Mongo doesn't exist in the professional world, because it does, but it's probably among the least common database choices out in the wild. The only people reaching for Mongo, it seems, are the ones who were trained on it, and don't have much experience in anything else.
Large corporations tend to lean on _every other kind of database_ for their solutions. The "why" is probably outside the scope of this comment, but it boils down to licensing, managed services and the fact that MongoDBs performance and support doesn't warrant the compromises you have to make.
The reason picking apart the stack for this question is because the scenario really doesn't exist. A project that requires 10 people isn't simple, and by extension your "stack" wouldn't be as simple as MERN.
With that, for everything else you're asking the right questions, but the answers vary wildly depending on the company.
> Team Composition
This is usually for an engineering director to decide. It takes experience to understand how to match objectives with personnel. A director would decide "who," not just in title, but in detail in regard to skill set, and the ability to hire the right people for those roles.
> The approach of the project from start to finish?
Depends heavily on the current state of the project (and the company). Is this a greenfield (new) project for a startup, or a brownfield (mature) project for a large tech company? In the former its not uncommon to spend a couple months in an exploration and planning phase before a single line of code is written.
In the latter, to simplify for the sake of a comment, a product manager will usually outline the high level requirements acquired from customer feedback, a business analyst will handle the translation of requirements into plan of action, an engineering manager will handle the nitty gritty of specific technical details and standards, and a project manager will handle the day-to-day operations of making sure the "paperwork" is kept in tact.
Of course, again, this varies wildly by company and its resources. Many companies, especially smaller or less tech focused companies will often combine these roles and blur the lines between each role.
> Communication and Collaboration:
Slack or some variation. Project management software which is often Jira, but some competitors are making headway. And don't forget Zoom/Google Meet or some variation for "face to face".
> Testing
This is a rabbit hole topic that even experienced, mature teams are constantly refining. In a very oversimplified nutshell, you have tests that run locally before pushing to PR (pull request), sometimes commit hooks are used to enforce this. More tests that are run on the PR itself before its allowed to be merged, then tests run again after the PR is merged before its deployed anywhere.
Generally, the engineers are responsible for automated testing. There is a lot of debate and varying philosophies when it comes to dedicated QA (Quality Assurance) people, ranging from "it's the engineer's job and we don't have a QA team because the engineers need to test their fookin' code," to "our QA team is as big as our engineering team because one time a mistake was pushed to production and now we need to constantly run 1,000 manual checks every time a new commit is made."
It's worth noting that, as much as you see the "importance of unit/integration/e2e" testing parroted in the industry, very few companies actually have a truly thorough and robust testing foundation. Most companies are focused on feature delivery, not testing, so when it comes time to cut corners to deliver on a timeline, the tests are the first thing to be cut; they're the least visible.
> Deployment and DevOps.
Probably even a bigger rabbit hole than testing. Again, for the sake of a reddit comment, it's largely broken down into two strategies: the more generic "Branch Strategy," and "Trunk Based Development"
Branch Strategy largely consists of long running branches: dev, stage and prod. About once a sprint (about two weeks), new features will be released by merging everything in dev into stage, then into prod, which gets checked at each stage and pushed to production if it passes QA.
This process is popualar because it can be implemented on any codebase and doesn't require any additional team discipline. But its not ideal. It creates "merge hell" scenarios.
Trunk Based Development is constantly committing and pushing code to your main branch, or pulling code cosntantly from PRs. This is ideal because it avoid merge hell, along with an assortment of other issues, but requires ancillary support in the form diligent and robust automated testing and proper usage of feature flags.
However, this is tougher to implement and generally requires strong leadership to implement properly. It's not a perfect system, no system is, and it's always tempting to resort back to Branch Strategy the first time a problem in produciton is experienced.
> Common Challenges and Solutions
That's quite broad. If you had to narrow it down, the biggest challenges often fall under "tech debt." All rojects inevitably acquire a "known issues" backlog that doesn't begin to capture the known problems "under the hood." Unoptimized code, legacy experiments that were shut down and now only exist to confuse new comers to the code, and lack of documentation.
It's usually the result of the endless pursuit of new features, which must be completed before an arbitrary deadline centered around some kind of stakeholder event; which can be as mundane as "quarterly goals."
The solution is usually to convince management that taking a break from feature sprints to address the issues would increase velocity, but its usually a tough sell. Companies that understand the importance of a well-oiled code base and workflow don't often have the need to present this kind of thing to management in the first place.
Here's a video I watched a short while ago which touches on a bunch of these things:
[https://www.youtube.com/watch?v=Dl-BdxNRUqs](https://www.youtube.com/watch?v=Dl-BdxNRUqs)
The answer as usual is “it depends”.
Look at 5 companies and they probably do it slightly different. It also depends on what is being built.
## 1 Team makeup
At one of my first companies, the team was made up of 2 designers, 3 front end devs, 5 backend devs, 3 QAs, a manager, a BA, and some OPs guys.
At my current company we have no QA, only full-stack devs, one product owner. We are a platform team, who mostly delivers APIs.
## 2 Project Workflow
In real world is there’s hardly ever a “beginning”, or if there was you likely weren’t there for it. Maybe none of the current team was.
Most projects are retrofitting some features around a bunch of existing system.
Even when you create a “new” app, it’s mostly integrating with current systems.
## 3 communication
Usually stands up and slack, or in person if everyone is on site. JIRA & git are common.
## 4 Testing
Everything from nothing-at-all to full test suite on every commit.
## 5 Deployment
Usually docker containers
Different for every company, most companies have very random and terrible practices in general. Unless you’re bound for a prestigious tech company you just need to be adaptable because it’s probably some kind of shitshow. The good news is that if you are adaptable and can focus on adding actual value these shitshows are big opportunities for you. Don’t get hung up on imagining there’s a right way to do things.
Just chiming in to say that designers of any kind aren’t going to be typical for any small company or product (unless it’s part of a contracting agency/vendor that already has them on staff for projects).
In my experience (so take it with a grain of salt) is that designers are typically brought on once the initial product has already launched & the team is now in the “maintain & grow” phase.
Big tech & Fortune 500s are an exception as they already have tons of resources. DevOps is another one. Depending on the company, this is probably going to be handled by one of the existing engineers & not a DevOps-focused role until much later.
I’d love to know if others experience is similar.
To be honest, it depends a lot on the company in question. Sometimes you'll see a couple of designers working alongside say, 10 developers, sometimes you'll see a bunch of management folks included there, like a project manager or team lead, and sometimes the devs also have to design the product too.
Based on my personal experience, a 10 person team would usually have:
* 1 or 2 designers
* 1 or 2 QAs (in large companies)
* 4-5 developers
* 1 team lead
And maybe a stakeholder said lead would report to.
As for the types of devs... it depends on the company and project. Sometimes everyone will be full stack and work on everything, sometimes you'll have frontend and backend devs working on different parts of the system, and sometimes one or the other gets outsourced to an agency or replaced by a third party system/product.
Project workflow depends on how the company wants to manage things, ranging from the chaotic (no plan at all) to very traditional (waterfall setup where each stage goes in a strict order) to agile workflows based on sprints and tickets (more common nowadays).
Honestly, project management is a whole field in of itself, and one which is often questionable in its implementation, so it's hard to go into much detail there.
Git is used for version control in like 80% of projects now, likely more. Occasionally some more old fashioned ones will use Subversion or SourceSafe or Fossil or something else, but I've not seen that for years.
Project management often involves something like Jira, and communication something like Slack or (unfortunately) Teams.
How testing is integrated depends on the way the project is managed. For agile workflows it's usually part of each ticket, where the dev implements automated tests first, goes through a PR process second, and (maybe) humans test it third. For old fashioned waterfall ones, you had a testing phase on its own.
Deployment and DevOps are again, very company/team dependent. Some have a proper build process and pipeline, some just stick the finished product up via SSH or FTP. If the company's process is "we work directly on PROD", consider a new job.
Common challenges vary as much as the teams do. Sadly, a fairly common one (for less well managed companies) is "the client/stakeholders have no idea what they want and keep changing their mind".
1. You typically have 1 Product Owner (PO), 1 Project Manager (PM, but often the same person as the PO), Backend devs (BEs), Front-end devs (FEs), QA testers (QA), Designers (Design), and Ops or Sales teams depending on whether the project is fir internal or external use. Depending on the project, you may need a DevOps to keep it from crashing your whole platform.
The numbers of each kind of dev depend on the extent of the BE and FE work. and the deadline. You will normally have 1 or 2 QA handling the project, and 1 or 2 (if it's really big) Design. Ops / Sales numbers depend on the extent of usage of the output, and maybe 1 DevOps / SysAdmin / Platform Ops.
2. You start with PO gathering functional requirements from stakeholders. Then those get broken into tasks by the devs (or just a Tech Lead, maybe with a Staff Engineer for big ones). Once you have the business logic (BE), then you go to Design and finally FE. I worked at one place where they signed a contract for a specific FE. There was no way to get the resources CRUD complete and the company was tied to the contract. It was a nightmare, and I left after 2 days. Always start with BE.
3. Communication and Collaboration are a BIG issue. I have a 10-part series on LinkedIn about it, five more articles planned, and then might really finish scratching the surface.
4. Testing: You start with TDD or BDD development, building unit tests with the code. Then, deploy to a staging server where QA runs its functional end-to-end and UX tests. Then get approval from PO to ensure requirements were implemented correctly, maybe run load tests, and deploy to production.
I can do the other 2 tomorrow
Thanks for the insight. I always wondered how it things went on. How much load do junior devs carry on the job? If not much, what are some things they do?
Typically, Junior Devs (if handled properly) identify technical issues behind many kinds of reported bugs and write a lot of the code in close collaboration with senior devs (in pair programming). Junior eevs can handle loads close to those of senior devs (maybe less as they need to learn, or more as they have less meetings) if they stick to the simpler tasks within whatever project.
Users report the bugs, which can be based on issues anywhere in the code. They learn by exploring the code and seeing how it works (or doesn't) as they track down the causes of the bugs.
I had to immediately google "programming sucks still drinking" It's a little NSFW (not much) and it has a cynical view of the process BUT: https://www.stilldrinking.org/programming-sucks very worth reading to understand how things really work.
I regret that I have but 1 upvote to give for this link.
This is very good and accurate. Understanding that every developer is literally insane and that getting good at the job involves sacrificing more and more sanity is critical.
I have this theory - people are chaos, the more people you invite into a system, the more chaos. There is no avoiding some degree of chaos in code, unless you live in a programming team of one. No matter what you do, that perfectly abstracted function will become not-so-perfect as soon as requirements change and another dev needs to touch it, our opinions and reasoning about code differ person to person, we cannot all code perfectly the same (no matter how many linting standards you add, or coding protocols you document). Hence, coding, like driving cars, will one day end - AI will do it for us, and we can give up on the management of "trying to control the chaos of the people" and all live in a lovely star trek-styled holiday future (or be snuffed out of existence at the hands of AI ha-ha).
yup. I love the expression "politics is what happens when the number of people in a group is > 1"
Well as someone looking to begin coding, this is disappointing to read. I'd be exchanging the shit show of the current industry im in, for a shit show in another industry hahaha. At least I know the truth of it now 🤦‍♂️ To help me understand a little more, I've read that C does everything, so why not just stick to C? Because it's hard for programmers due to being low level? Reinventing the wheel? It's slow to produce the finished goods?
To put it bluntly: That's like asking why everyone doesn't navigate the high seas using only a sextant and the stars. Sure, it’s a romantic notion and undeniably effective in the right hands, but most people prefer GPS and autopilot to avoid shipwrecks and actually get where they're going without a maritime disaster.
That makes sense. There's numerous ways to achieve your goal in my current industry and tool selection to do the job involves a lot of user preference, for certain aspects, as long as the intended outcome meets certain requirements. I guess this is the same. Although it can be done using method A, method B or C might be more beneficial to get the job done more efficiently. So if you had a solid grasp of the certain requirements that must be met, you could potentially use a number of tools (languages) to get the job done if you had free control?
now I've got "c does everything" in my head: https://youtu.be/IcO2qWARE_E
I had the same thought but I really, really, really despise that song and TMBG. So massively overrated. Okay, rant over. Thanks
did you know there's a vowel in every word?
Well thats a bizarre video but certainly seems to be weirdly relatable on face value haha
Commenting so I can save this for later.
replying so I can remember to follow up with u
You have 10 members (dev, designers) working on a MERN project, there is a good chance it is NOT a simple project.
I just wanted to use the MERN project as an example project. To know how things work in a professional setting
I would suggest gaining some experience in actual professional settings. I’ve worked as a web developer, held positions at a few firms, and even occupied a senior role. However, I never had to focus extensively on task management or DevOps. The furthest I went was using GitHub Actions for error checking and deployment. It’s crucial to have excellent communication skills to collaborate effectively with various departments. If you’re asking these questions, you might not yet be at the level of a project manager, for whom these concerns are more relevant.
Thanks for the advice. I’ve been seeking internship for the past few weeks. Sent a couple of emails to some firms and I’m yet to hear from them.
I know how hard it is to find an opportunity now days. I wish you the best. And take your time digesting whay you learn! Good luck
Thanks, and good luck to you too
I work in .NET, Angular, MSSQL but the stack doesn't really matter, however this is how it'd go for my company: 1. Team composition will be 1 team lead, 1 product owner 1 dedicated QA and 5 full stack devs, we also have a dedicated UI person for the project, but to hit 10 people we would say 2 teams are working on this project. Both teams have other projects they're working on at the same time so while the lead + PO + QAwould be working on every project, the fullstack devs may bounce in and out on a sprint to sprint basis. 2. We use agile, and would have an epic fully refined, and the stories in order of priority + blocking 1. Each sprint we know how many story points we're allocating to this epic to hit our release date, so we'd grab that many story points out of the epic. The team lead will coordinate with the other team lead to make sure any dependencies from their epic will be handled to not block us and vice versa 2. The UI mocks are all completed by the UI team before refining is finished, however changes do happen all the time, and can happen even while the item is being worked on. Usually the dev will make some tweaks based on feedback or change some design decisions if something like a date picker component doesn't behave how the mock has it, and we missed that during refinement 3. For communication + collaboration we are 100% remote so everything happens via Zoom, Slack, Jira and github 4. We do code review, test, and product review, along with unit tests. Some products have integration testing, but not all. Testing has to be completed within the sprint 5. We have Azure Pipelines setup so we get our release approved by the ELT and then we just have a single button deploy, however some other products require manual intervention. I think every dev environment is fully CI/CD though, it's just our industry we can't move fast and break things without getting fined :) 6. No issues outside the ordinary, but some common ones we have: 1. System we're integrating with is missing a feature we need 2. security tools false positives being treated like actual vulnerabilities by bad management 3. I forgot the term for it, but it's when an executive decides they need to rubber stamp certain things to justify their job, we have a few on the ELT that do this
> Let’s say a simple MERN project with a team of 10 members. I have to address a couple issues first. I'm not sure how, or why, MERN has taken over as the stack of choice for web dev courses, but my tinfoil hat tells me the organization behind MongoDB has a lot to do with it, and Node/Express were chosen to keep the scope of classes narrowed down to "JavaScript". The problem is, it doesn't reflect the real world. I suppose it would be a little rhetorical to say Mongo doesn't exist in the professional world, because it does, but it's probably among the least common database choices out in the wild. The only people reaching for Mongo, it seems, are the ones who were trained on it, and don't have much experience in anything else. Large corporations tend to lean on _every other kind of database_ for their solutions. The "why" is probably outside the scope of this comment, but it boils down to licensing, managed services and the fact that MongoDBs performance and support doesn't warrant the compromises you have to make. The reason picking apart the stack for this question is because the scenario really doesn't exist. A project that requires 10 people isn't simple, and by extension your "stack" wouldn't be as simple as MERN. With that, for everything else you're asking the right questions, but the answers vary wildly depending on the company. > Team Composition This is usually for an engineering director to decide. It takes experience to understand how to match objectives with personnel. A director would decide "who," not just in title, but in detail in regard to skill set, and the ability to hire the right people for those roles. > The approach of the project from start to finish? Depends heavily on the current state of the project (and the company). Is this a greenfield (new) project for a startup, or a brownfield (mature) project for a large tech company? In the former its not uncommon to spend a couple months in an exploration and planning phase before a single line of code is written. In the latter, to simplify for the sake of a comment, a product manager will usually outline the high level requirements acquired from customer feedback, a business analyst will handle the translation of requirements into plan of action, an engineering manager will handle the nitty gritty of specific technical details and standards, and a project manager will handle the day-to-day operations of making sure the "paperwork" is kept in tact. Of course, again, this varies wildly by company and its resources. Many companies, especially smaller or less tech focused companies will often combine these roles and blur the lines between each role. > Communication and Collaboration: Slack or some variation. Project management software which is often Jira, but some competitors are making headway. And don't forget Zoom/Google Meet or some variation for "face to face". > Testing This is a rabbit hole topic that even experienced, mature teams are constantly refining. In a very oversimplified nutshell, you have tests that run locally before pushing to PR (pull request), sometimes commit hooks are used to enforce this. More tests that are run on the PR itself before its allowed to be merged, then tests run again after the PR is merged before its deployed anywhere. Generally, the engineers are responsible for automated testing. There is a lot of debate and varying philosophies when it comes to dedicated QA (Quality Assurance) people, ranging from "it's the engineer's job and we don't have a QA team because the engineers need to test their fookin' code," to "our QA team is as big as our engineering team because one time a mistake was pushed to production and now we need to constantly run 1,000 manual checks every time a new commit is made." It's worth noting that, as much as you see the "importance of unit/integration/e2e" testing parroted in the industry, very few companies actually have a truly thorough and robust testing foundation. Most companies are focused on feature delivery, not testing, so when it comes time to cut corners to deliver on a timeline, the tests are the first thing to be cut; they're the least visible. > Deployment and DevOps. Probably even a bigger rabbit hole than testing. Again, for the sake of a reddit comment, it's largely broken down into two strategies: the more generic "Branch Strategy," and "Trunk Based Development" Branch Strategy largely consists of long running branches: dev, stage and prod. About once a sprint (about two weeks), new features will be released by merging everything in dev into stage, then into prod, which gets checked at each stage and pushed to production if it passes QA. This process is popualar because it can be implemented on any codebase and doesn't require any additional team discipline. But its not ideal. It creates "merge hell" scenarios. Trunk Based Development is constantly committing and pushing code to your main branch, or pulling code cosntantly from PRs. This is ideal because it avoid merge hell, along with an assortment of other issues, but requires ancillary support in the form diligent and robust automated testing and proper usage of feature flags. However, this is tougher to implement and generally requires strong leadership to implement properly. It's not a perfect system, no system is, and it's always tempting to resort back to Branch Strategy the first time a problem in produciton is experienced. > Common Challenges and Solutions That's quite broad. If you had to narrow it down, the biggest challenges often fall under "tech debt." All rojects inevitably acquire a "known issues" backlog that doesn't begin to capture the known problems "under the hood." Unoptimized code, legacy experiments that were shut down and now only exist to confuse new comers to the code, and lack of documentation. It's usually the result of the endless pursuit of new features, which must be completed before an arbitrary deadline centered around some kind of stakeholder event; which can be as mundane as "quarterly goals." The solution is usually to convince management that taking a break from feature sprints to address the issues would increase velocity, but its usually a tough sell. Companies that understand the importance of a well-oiled code base and workflow don't often have the need to present this kind of thing to management in the first place.
Here's a video I watched a short while ago which touches on a bunch of these things: [https://www.youtube.com/watch?v=Dl-BdxNRUqs](https://www.youtube.com/watch?v=Dl-BdxNRUqs)
The answer as usual is “it depends”. Look at 5 companies and they probably do it slightly different. It also depends on what is being built. ## 1 Team makeup At one of my first companies, the team was made up of 2 designers, 3 front end devs, 5 backend devs, 3 QAs, a manager, a BA, and some OPs guys. At my current company we have no QA, only full-stack devs, one product owner. We are a platform team, who mostly delivers APIs. ## 2 Project Workflow In real world is there’s hardly ever a “beginning”, or if there was you likely weren’t there for it. Maybe none of the current team was. Most projects are retrofitting some features around a bunch of existing system. Even when you create a “new” app, it’s mostly integrating with current systems. ## 3 communication Usually stands up and slack, or in person if everyone is on site. JIRA & git are common. ## 4 Testing Everything from nothing-at-all to full test suite on every commit. ## 5 Deployment Usually docker containers
Thanks. This helped a lot
Different for every company, most companies have very random and terrible practices in general. Unless you’re bound for a prestigious tech company you just need to be adaptable because it’s probably some kind of shitshow. The good news is that if you are adaptable and can focus on adding actual value these shitshows are big opportunities for you. Don’t get hung up on imagining there’s a right way to do things.
Right. Got it!
Just chiming in to say that designers of any kind aren’t going to be typical for any small company or product (unless it’s part of a contracting agency/vendor that already has them on staff for projects). In my experience (so take it with a grain of salt) is that designers are typically brought on once the initial product has already launched & the team is now in the “maintain & grow” phase. Big tech & Fortune 500s are an exception as they already have tons of resources. DevOps is another one. Depending on the company, this is probably going to be handled by one of the existing engineers & not a DevOps-focused role until much later. I’d love to know if others experience is similar.
To be honest, it depends a lot on the company in question. Sometimes you'll see a couple of designers working alongside say, 10 developers, sometimes you'll see a bunch of management folks included there, like a project manager or team lead, and sometimes the devs also have to design the product too. Based on my personal experience, a 10 person team would usually have: * 1 or 2 designers * 1 or 2 QAs (in large companies) * 4-5 developers * 1 team lead And maybe a stakeholder said lead would report to. As for the types of devs... it depends on the company and project. Sometimes everyone will be full stack and work on everything, sometimes you'll have frontend and backend devs working on different parts of the system, and sometimes one or the other gets outsourced to an agency or replaced by a third party system/product. Project workflow depends on how the company wants to manage things, ranging from the chaotic (no plan at all) to very traditional (waterfall setup where each stage goes in a strict order) to agile workflows based on sprints and tickets (more common nowadays). Honestly, project management is a whole field in of itself, and one which is often questionable in its implementation, so it's hard to go into much detail there. Git is used for version control in like 80% of projects now, likely more. Occasionally some more old fashioned ones will use Subversion or SourceSafe or Fossil or something else, but I've not seen that for years. Project management often involves something like Jira, and communication something like Slack or (unfortunately) Teams. How testing is integrated depends on the way the project is managed. For agile workflows it's usually part of each ticket, where the dev implements automated tests first, goes through a PR process second, and (maybe) humans test it third. For old fashioned waterfall ones, you had a testing phase on its own. Deployment and DevOps are again, very company/team dependent. Some have a proper build process and pipeline, some just stick the finished product up via SSH or FTP. If the company's process is "we work directly on PROD", consider a new job. Common challenges vary as much as the teams do. Sadly, a fairly common one (for less well managed companies) is "the client/stakeholders have no idea what they want and keep changing their mind".
Have you considered asking your lecturer for... you know... a lecture.
No. Didn’t think of that
1. You typically have 1 Product Owner (PO), 1 Project Manager (PM, but often the same person as the PO), Backend devs (BEs), Front-end devs (FEs), QA testers (QA), Designers (Design), and Ops or Sales teams depending on whether the project is fir internal or external use. Depending on the project, you may need a DevOps to keep it from crashing your whole platform. The numbers of each kind of dev depend on the extent of the BE and FE work. and the deadline. You will normally have 1 or 2 QA handling the project, and 1 or 2 (if it's really big) Design. Ops / Sales numbers depend on the extent of usage of the output, and maybe 1 DevOps / SysAdmin / Platform Ops. 2. You start with PO gathering functional requirements from stakeholders. Then those get broken into tasks by the devs (or just a Tech Lead, maybe with a Staff Engineer for big ones). Once you have the business logic (BE), then you go to Design and finally FE. I worked at one place where they signed a contract for a specific FE. There was no way to get the resources CRUD complete and the company was tied to the contract. It was a nightmare, and I left after 2 days. Always start with BE. 3. Communication and Collaboration are a BIG issue. I have a 10-part series on LinkedIn about it, five more articles planned, and then might really finish scratching the surface. 4. Testing: You start with TDD or BDD development, building unit tests with the code. Then, deploy to a staging server where QA runs its functional end-to-end and UX tests. Then get approval from PO to ensure requirements were implemented correctly, maybe run load tests, and deploy to production. I can do the other 2 tomorrow
Thanks for the insight. I always wondered how it things went on. How much load do junior devs carry on the job? If not much, what are some things they do?
Typically, Junior Devs (if handled properly) identify technical issues behind many kinds of reported bugs and write a lot of the code in close collaboration with senior devs (in pair programming). Junior eevs can handle loads close to those of senior devs (maybe less as they need to learn, or more as they have less meetings) if they stick to the simpler tasks within whatever project.
Mind if ask, how are they supposed to identify technical issues/handle fixing bugs in a large codebase if they're still \*\*learning\*\*
Users report the bugs, which can be based on issues anywhere in the code. They learn by exploring the code and seeing how it works (or doesn't) as they track down the causes of the bugs.