Iyfjky

Question

I understand that there are things in software development that cannot be learned in school, even in a CS degree. As discussed, for example here, these include things like best practices, design patterns, testing etc.

But what if one was not just learning things theoretically, but on the job? I am referring to being a solo developer, perhaps at a startup with no previously established software group. An advantage of this might be the opportunity on building the entire software stack from scratch, which seems to be a rare and invaluable experience that someone working in an established team might never get to encounter!

On the other hand, the solo developer might miss out on things like daily mentorship, constant peer-wise code review etc.

What if there are mitigating factors: Say if the solo developer had access to experienced developers for occasional consultation, but not as colleagues. Or if the solo developer has the theoretical underpinnings, say from a formal education in CS and knew what and where to look for information?

The key question: Are there things in software development that simply cannot be learned unless working in a group? If so, is this 'gap' a deal-breaker for future employment as a developer outside of solo development?

Good question, I personally went with a startup and found I gained a lot of knowledge by dealing with the entirety of my projects. On the other hand my code quality was not to the same standard as when I joined an established team. — Mar 29 '14 at 11:46
I believe the programmers.stackexchange forum explicitly doesn't welcome career-related questions. Question has now been edited to be more general, perhaps one can consider re-opening it to responses? — Mar 29 '14 at 15:55
Hi @user18152, great edits! In its original form, I wouldn't have reopened it, and in this form I'm not 100% positive this won't get closed again, but I'm going to go ahead and take this off hold because you put a lot of work into editing it to make it something that could be answered with backed up information and also be useful to other people working with legacy technologies in their careers. — Mar 29 '14 at 16:23
Answer Guidance: For those who answer this... Workplace SE is not a personal advice forum. Answers must be backed up with something that tells future readers you're qualified to answer this. See the back it up rule for details. Hope this helps! — Mar 29 '14 at 16:25

NotVonKaiser 6,5151533 · Accepted Answer · 2014-03-30 02:26:11Z

The definitive answer that I have is... sort of. No, you're not necessarily going to learn, like, OOP techniques in a group situation which you could never have learned on your own, but there are still a number of things you can learn in a team setting:

How to work as a team. I realize this is kind of a circular answer but it does bear stating nevertheless. You can read all you want about team programming techniques but until you get into a situation where you're pounding out a piece of code that is dependent on code that is currently being pounded out by a guy sitting 2 cubicles away from you, you're not ever going to quite know what all that's about.

A lot of techniques like Scrum kind of need to be done to be learned. I always think there are two kinds of knowledge: book knowledge and practical knowledge. Programming is interesting in that a lot of the time there isn't a lot of difference between the two: if you already have the skill of programming you can pick up a new API or even a new language by reading a book or using your Google-fu skills. However, there are some areas where that technique doesn't exactly hold water.

Some of those XP/Agile/Scrum type techniques are one of those. Sure, you probably had it drilled into you in some class or other you had at school how important a design document is, and maybe you even watched a video about how to conduct a daily Scrum session or write a story or what have you, but I feel like until you actually do this or at least see it done as a regular part of your job, you don't really get what these things really and actually mean (this goes for management just as much as devs: I've seen managers routinely turn Scrum meetings into regular old bane-to-programmers hour-long administrative sessions, and what that almost always comes down to is that they aren't that familiar with how these things are supposed to be run and why). I'm not saying that this is rocket science or anything but it is an applied skill more than a book-learned one.

The importance of clean design and structure. One of the "benefits" - and I use quotes around benefits for a reason - of doing solo programming is that you often just need to make something work and it doesn't really matter how obscure the code looks on the back end. Once you do a few code reviews with others, you quickly begin to realize how important commenting your own code can be, not to mention the notion (which, granted, already exists in XP and which is for sure taught in books) that ideally the code ought to be clean enough to speak for itself when it comes to comment time.

I think this goes beyond "hey, don't use x and y for all your variable names" (although that, too, is a lesson some programmers learn for the first time when doing code reviews) and often into how to effectively communicate. That's a very important and underrated skill.

More heads = more ideas. Programming is a fairly creative endeavor. Generally, when faced with a problem, you could conceivably come up with 5 or 10 different ways of solving it, each with their own individual advantages and disadvantages. Well, when you get together with other people you will often find that they have 5 or 10 ways of solving an issue as well - and those ways are mutually exclusive from yours. This applies even when you're in a position where you have a lead dev who is pre-writing classes and even methods for you to just fill in.

It can be very easy to get tunnel vision on a problem, getting stuck in programming something in a certain way but not quite figuring it out where another way of solving the same issue would have been done in half the time you took or less. It's cool; we all do it. However, it's good to stay in that creative mindset and just being able to bounce ideas of of other people and/or be a receptacle for bounced ideas builds some very useful skills.

How to work with other people. This is also a redundant-sounding one but it is nevertheless true. I realize that programming can feel like an individual thing: even when you're assigned a task as part of a larger picture, it is usually you in the end who is responsible for the implementation of that task. Nevertheless, you do work with other people. It's surprising to me (a person who worked in many non-programmer jobs before moving into software development) how many people in this industry never bothered to develop people skills.

I guess it's a sign of how much management will put up with a good dev if they are producing, but here's the thing: your chances of being the best dev EVAR are very, very low, and if you're not the greatest dev who ever devved there is always the chance that you will wind up working with someone who is better at what you're doing than you. Many times, when decisions have to be made as to whether or not to extend someone's contract or, what is worse, figure out who to lay off in bad times for a company, the decision as to who to keep and who to sack is not based on pure skill but on who is easiest to work with.

There are lots and lots of "soft skills" that go into that, and I simply do not think it's possible to learn these from a book. How to persuade people into agreeing with you without making them feel bad. How to correct a person you work with without them getting offended (if you can acquire this skill with some ability, you are ahead of maybe 90% of all devs who are out there). How to accept criticism from others, particularly unfocused criticism from a non-tech savvy client. How to explain what the heck you're doing without sounding like you're trying to mislead folks with jargon or blather on and on for 5 minutes. And so on and so forth.

There are really good reasons why most companies will prefer to hire an experienced programmer over one who just came out of even a highly regarded school. Programming, frankly, is not nuclear physics. I'm not saying it's easy, but it's the kind of thing you can learn on your own. What you can't learn on your own are team skills.

I really like your answer. I am am a self-thought SOftware Engineer at a small company who does produce fairly good code (as stated by friends who have studied the tpopic). But the code is still not as good as it should be - and it is very hard to improve after a certain point because you can learn such things in a team much easier than alone. Spotting bad habbits or things you don't know is incredibly hard, when you work alone. — Mar 30 '14 at 6:06

Steve 3,70611127 · Answer 2 · 2014-03-29 21:31:57Z

Absolutely, in a nutshell it's call teamwork! There's very little technical knowledge that you can't pick up on your own in one form or another. But the bottom line is that working in a team environment can be a great learning experience. There are a lot of other benefits to working in a team.

The ability to share and bounce ideas off of knowledgeable team members is a great learning experience. Often times you'll see things from a different perspective from your current one, and this is an extremely valuable skill and mindset to develop.

You'll also gain insight to the combined years of experience that the team has. Believe me they've more than likely tried your approach before and learned from the experience; their insight into the pitfalls and gotcha's that they ran in to will save you a lot of headache and pain.

I've said for years that programming is as much artistic/creative as it is technical. The technical knowledge comes from school and training, where the artistic/creative aspects come from experience. Working in a team environment provides you an immediate pool of experience to pull from.

NotVonKaiser 6,5151533 · Accepted Answer · 2014-03-30 02:26:11Z

The definitive answer that I have is... sort of. No, you're not necessarily going to learn, like, OOP techniques in a group situation which you could never have learned on your own, but there are still a number of things you can learn in a team setting:

How to work as a team. I realize this is kind of a circular answer but it does bear stating nevertheless. You can read all you want about team programming techniques but until you get into a situation where you're pounding out a piece of code that is dependent on code that is currently being pounded out by a guy sitting 2 cubicles away from you, you're not ever going to quite know what all that's about.

A lot of techniques like Scrum kind of need to be done to be learned. I always think there are two kinds of knowledge: book knowledge and practical knowledge. Programming is interesting in that a lot of the time there isn't a lot of difference between the two: if you already have the skill of programming you can pick up a new API or even a new language by reading a book or using your Google-fu skills. However, there are some areas where that technique doesn't exactly hold water.

Some of those XP/Agile/Scrum type techniques are one of those. Sure, you probably had it drilled into you in some class or other you had at school how important a design document is, and maybe you even watched a video about how to conduct a daily Scrum session or write a story or what have you, but I feel like until you actually do this or at least see it done as a regular part of your job, you don't really get what these things really and actually mean (this goes for management just as much as devs: I've seen managers routinely turn Scrum meetings into regular old bane-to-programmers hour-long administrative sessions, and what that almost always comes down to is that they aren't that familiar with how these things are supposed to be run and why). I'm not saying that this is rocket science or anything but it is an applied skill more than a book-learned one.

The importance of clean design and structure. One of the "benefits" - and I use quotes around benefits for a reason - of doing solo programming is that you often just need to make something work and it doesn't really matter how obscure the code looks on the back end. Once you do a few code reviews with others, you quickly begin to realize how important commenting your own code can be, not to mention the notion (which, granted, already exists in XP and which is for sure taught in books) that ideally the code ought to be clean enough to speak for itself when it comes to comment time.

I think this goes beyond "hey, don't use x and y for all your variable names" (although that, too, is a lesson some programmers learn for the first time when doing code reviews) and often into how to effectively communicate. That's a very important and underrated skill.

More heads = more ideas. Programming is a fairly creative endeavor. Generally, when faced with a problem, you could conceivably come up with 5 or 10 different ways of solving it, each with their own individual advantages and disadvantages. Well, when you get together with other people you will often find that they have 5 or 10 ways of solving an issue as well - and those ways are mutually exclusive from yours. This applies even when you're in a position where you have a lead dev who is pre-writing classes and even methods for you to just fill in.

It can be very easy to get tunnel vision on a problem, getting stuck in programming something in a certain way but not quite figuring it out where another way of solving the same issue would have been done in half the time you took or less. It's cool; we all do it. However, it's good to stay in that creative mindset and just being able to bounce ideas of of other people and/or be a receptacle for bounced ideas builds some very useful skills.

How to work with other people. This is also a redundant-sounding one but it is nevertheless true. I realize that programming can feel like an individual thing: even when you're assigned a task as part of a larger picture, it is usually you in the end who is responsible for the implementation of that task. Nevertheless, you do work with other people. It's surprising to me (a person who worked in many non-programmer jobs before moving into software development) how many people in this industry never bothered to develop people skills.

I guess it's a sign of how much management will put up with a good dev if they are producing, but here's the thing: your chances of being the best dev EVAR are very, very low, and if you're not the greatest dev who ever devved there is always the chance that you will wind up working with someone who is better at what you're doing than you. Many times, when decisions have to be made as to whether or not to extend someone's contract or, what is worse, figure out who to lay off in bad times for a company, the decision as to who to keep and who to sack is not based on pure skill but on who is easiest to work with.

There are lots and lots of "soft skills" that go into that, and I simply do not think it's possible to learn these from a book. How to persuade people into agreeing with you without making them feel bad. How to correct a person you work with without them getting offended (if you can acquire this skill with some ability, you are ahead of maybe 90% of all devs who are out there). How to accept criticism from others, particularly unfocused criticism from a non-tech savvy client. How to explain what the heck you're doing without sounding like you're trying to mislead folks with jargon or blather on and on for 5 minutes. And so on and so forth.

There are really good reasons why most companies will prefer to hire an experienced programmer over one who just came out of even a highly regarded school. Programming, frankly, is not nuclear physics. I'm not saying it's easy, but it's the kind of thing you can learn on your own. What you can't learn on your own are team skills.

I really like your answer. I am am a self-thought SOftware Engineer at a small company who does produce fairly good code (as stated by friends who have studied the tpopic). But the code is still not as good as it should be - and it is very hard to improve after a certain point because you can learn such things in a team much easier than alone. Spotting bad habbits or things you don't know is incredibly hard, when you work alone. — Mar 30 '14 at 6:06

Steve 3,70611127 · Answer 4 · 2014-03-29 21:31:57Z

Absolutely, in a nutshell it's call teamwork! There's very little technical knowledge that you can't pick up on your own in one form or another. But the bottom line is that working in a team environment can be a great learning experience. There are a lot of other benefits to working in a team.

The ability to share and bounce ideas off of knowledgeable team members is a great learning experience. Often times you'll see things from a different perspective from your current one, and this is an extremely valuable skill and mindset to develop.

You'll also gain insight to the combined years of experience that the team has. Believe me they've more than likely tried your approach before and learned from the experience; their insight into the pitfalls and gotcha's that they ran in to will save you a lot of headache and pain.

I've said for years that programming is as much artistic/creative as it is technical. The technical knowledge comes from school and training, where the artistic/creative aspects come from experience. Working in a team environment provides you an immediate pool of experience to pull from.

Search This Blog

Iyfjky

Are there things that simply cannot be self-taught in software development unless working in a group? [closed]

closed as primarily opinion-based by Jim G., Monica Cellioâ™¦, bethlakshmi, jcmeloni, Michael Grubey Apr 1 '14 at 12:18

closed as primarily opinion-based by Jim G., Monica Cellioâ™¦, bethlakshmi, jcmeloni, Michael Grubey Apr 1 '14 at 12:18

closed as primarily opinion-based by Jim G., Monica Cellioâ™¦, bethlakshmi, jcmeloni, Michael Grubey Apr 1 '14 at 12:18

closed as primarily opinion-based by Jim G., Monica Cellioâ™¦, bethlakshmi, jcmeloni, Michael Grubey Apr 1 '14 at 12:18

2 Answers
2

2 Answers
2

2 Answers
2

Comments

Post a Comment

Popular posts from this blog

What does second last employer means? [closed]

List of Gilmore Girls characters

Confectionery

Category

Random preview

Are there things that simply cannot be self-taught in software development unless working in a group? [closed]

closed as primarily opinion-based by Jim G., Monica Cellioâ™¦, bethlakshmi, jcmeloni, Michael Grubey Apr 1 '14 at 12:18

closed as primarily opinion-based by Jim G., Monica Cellioâ™¦, bethlakshmi, jcmeloni, Michael Grubey Apr 1 '14 at 12:18

closed as primarily opinion-based by Jim G., Monica Cellioâ™¦, bethlakshmi, jcmeloni, Michael Grubey Apr 1 '14 at 12:18

closed as primarily opinion-based by Jim G., Monica Cellioâ™¦, bethlakshmi, jcmeloni, Michael Grubey Apr 1 '14 at 12:18

2 Answers 2

2 Answers 2

2 Answers 2

Comments

Post a Comment

Popular posts from this blog

What does second last employer means? [closed]

List of Gilmore Girls characters

Confectionery

2 Answers
2

2 Answers
2

2 Answers
2