I studied computer science as well and I share this sentiment.
Although I’m happy about my degree because I’ve learned many things I would otherwise miss, I also wish my degree prepared me more for the industry. There’s a disconnect between academia and the industry.
What I’m mostly concerned with is how to build software that can grow with 10ish team members. I find it hard to find good academic sources on this matter.
It’s methodology. Basically what you need is the correct amount of process - you can pick agile or scrum or whatever, and then you follow it to the amount that it makes sense. If you over-adhere to it, it slows things down to a crawl
Once you get up to 10 team members, you need to do things like feature branches, code reviews, and rigid style. You should also add in tests… At 10 you don’t have to have full coverage, but you need to be able to exercise your system enough to know when something breaks immediately
You also need ownership. You need one primary person who is the heart and soul of the code base, and they’re going to be the one who knows the whole thing and gives everyone direction. You can spin off another team at solid interface points, like an API or a plug in system, but you need one person who owns the core system and holds the code debt back
You also can add in code pipelines, enforce docstrings to generate documentation, you need diagrams so people understand how things flow through the system, etc
Ultimately, a lot of it comes down to mentorship. You have to be very hands on teaching people how the code works, and really hold their hand until they gain proficiency over an area. Then let them be secondary owners over that part of the symptom… And you have to make sure to stick them in a place where they’ll be a benefit - as you grow in numbers, it gets easier for each new person to be a drain on progress.
I’m not sure about academic sources…I dropped a lot of keywords in there that might help search, but ultimately it’s about team culture. You can’t just shove it all in at once, you have to slowly add new processes and make sure everyone is moving in the same direction
I know these concepts - after working in the industry for a while. Computer science education barely touched these topics. One professor was passionate enough to hint at test driven development, but that’s about it.
I had a nice teacher who gave us IRL clients over the course of a full year, and basically guided us through the process while teaching us methodology theoretically as we went through the process
I don’t think there’s a better way, honestly the theory is important, but methodology is learned by doing. I really benefitted by learning from my brother… He taught me best practices as he went through school and the workforce. So I pay it forward
I think courses should focus more on teaching how to use libraries and debug tools… Past that, you get into skills that can’t be taught, only learned
I studied computer science as well and I share this sentiment.
Although I’m happy about my degree because I’ve learned many things I would otherwise miss, I also wish my degree prepared me more for the industry. There’s a disconnect between academia and the industry.
What I’m mostly concerned with is how to build software that can grow with 10ish team members. I find it hard to find good academic sources on this matter.
It’s methodology. Basically what you need is the correct amount of process - you can pick agile or scrum or whatever, and then you follow it to the amount that it makes sense. If you over-adhere to it, it slows things down to a crawl
Once you get up to 10 team members, you need to do things like feature branches, code reviews, and rigid style. You should also add in tests… At 10 you don’t have to have full coverage, but you need to be able to exercise your system enough to know when something breaks immediately
You also need ownership. You need one primary person who is the heart and soul of the code base, and they’re going to be the one who knows the whole thing and gives everyone direction. You can spin off another team at solid interface points, like an API or a plug in system, but you need one person who owns the core system and holds the code debt back
You also can add in code pipelines, enforce docstrings to generate documentation, you need diagrams so people understand how things flow through the system, etc
Ultimately, a lot of it comes down to mentorship. You have to be very hands on teaching people how the code works, and really hold their hand until they gain proficiency over an area. Then let them be secondary owners over that part of the symptom… And you have to make sure to stick them in a place where they’ll be a benefit - as you grow in numbers, it gets easier for each new person to be a drain on progress.
I’m not sure about academic sources…I dropped a lot of keywords in there that might help search, but ultimately it’s about team culture. You can’t just shove it all in at once, you have to slowly add new processes and make sure everyone is moving in the same direction
I know these concepts - after working in the industry for a while. Computer science education barely touched these topics. One professor was passionate enough to hint at test driven development, but that’s about it.
I had a nice teacher who gave us IRL clients over the course of a full year, and basically guided us through the process while teaching us methodology theoretically as we went through the process
I don’t think there’s a better way, honestly the theory is important, but methodology is learned by doing. I really benefitted by learning from my brother… He taught me best practices as he went through school and the workforce. So I pay it forward
I think courses should focus more on teaching how to use libraries and debug tools… Past that, you get into skills that can’t be taught, only learned