Indie developers think almost exclusively about if the product is good and sacrifice project/code quality at every turn in order to ship it.
Non-indie devs think almost exclusively about if the code is good, and sacrifice timelines, budgets, and actually shipping something at all at every turn.
Communication. On PR, on reviews, on refactoring, on asking help. The manager of my team says that the difference between a senior and a junior/mid dev, is hardly technical, but on when and how they communicate.
All those things make for a subtle art that is only learn in teams and need to be adapted to each team member, which takes time. It's something that is harder to learn if you jump from project to project (although, there are ways).
1.) Documentation: Indie developers don't document. If you do , you are either a maverick or a liar.
2.) Depending on Team: As an indie developer I had habit of soloing on everything. After a certain time it was bit infuriating being told to not do work ¯_(ツ)_/¯ .
3.) Libraries & Licensing : Indie developers tend to use everything available at their disposal regardless of the license involved.. In a company environment libraries have to be pre approved for usage. Plus developers are asked to not use GPL licenses or strict copyleft.
4.) Career Path/ Hierarchy : Indie developers don't think about career paths. While they get to Senior Developers roles faster. Indie developers are out of depth or experience for the Architect or other techno management roles.
5.)Vision: This is debatable. Indie developers don't get big projects or projects which connect to multiple systems. People in teams tend to get to work on bigger projects. But Indie developers can think of an project end-to-end. People in teams usually have work on a small part in a large vision without having access to see how everything wires up. So basically someone who has worked on teams exclusively cannot work on end to end projects.
Max is a startup software engineer. He seeks to use what he has learnt as a startup founder and tech community leader to solves hard problems with innovate products or services.
I was just perusing some code from my brother's project. He is a very effective self-taught developer, but it is interesting to see what falls by the wayside in that environment.... And what jumps out to me is... Dependency management.
His projects have a lot of non-updated dependencies, which I feel is one of those things which you'd do based on the culture of a team and not something you'd just "learn" independently.
I know he does update his dependencies from time to time, but not on a regular basis. I know some teams probably have bad cultures around this as well, but I know personally my values around updating dependencies are influenced by the habits of the software teams I've been on.
Most of my personal projects have zero dependencies. Being self taught from an early age on a ZX Spectrum instilled a mindset of wanting to understand and build as much of every project as I (reasonably) can
I've seen plenty of university-trained software engineers leave dependencies non-updated from time to time, myself included. It's a risk-reward and "Is it worth the time?" trade-off, and often the answer is "No it's not worth the time"
Testing (not just unit tests), complex data migrations (in some cases), communication between teams, security (in some cases), the value of pair programming, knowledge sharing.
This won't apply to all indie devs but it was definitely stuff I battled with before working in teams and stuff I've seen indie dev friends not learn
Graduated in Digital Media M.Sc. now developing the next generation of educational software. Since a while I develop full stack in Javascript using Meteor. Love fitness and Muay Thai after work.
I am just part time indie worker but I may ask: What about indie open source work? It's nothing where you actually generate income but you do it for DRY, learning, proving and generating a portfolio for future contracts, generating income.
In my open source work I focus a lot on code quality, documentation, review process etc. and this tends to influence my indie work a lot, so I already try to write maintainable code when getting a contract mostly because I don't want to fiddle with messy code when getting a follow up contract and things get complicated.
I think vision of yourself and how you want to work is important here: I want to be perceived as an engineer who delivers high quality (which is why I want to charge the according price).
One thing though regarding licenses: I care if the client cares, otherwise all-in
Born, raise in Tijuana, MX. With a degree in Philosophy, have worked as janitor, sales person, pizza delivery boy, teacher, press operator, prepress, desktop Publisher, and for the last 19 years dev
I've been in both sides, and as an independent or more factual, as a solo developer in a advertisement team I was very happy ignoring a lot of code quality strategies, I don't know how much is this due the lack of the current online communities, and how much was just me being absorb in the glamour of ad agencies and focusing on bells and whistles. But I kind of remember the feeling of no one understanding why the things couldn't be done as the client "demanded", and me faling to come up with the technical argument.
The first thing I learned when working in a more Tech oriented team, in the mid 2000's was to look up for the community to backup my decisions. The moment I start going to tech conventions and reading in forums more about empathy with fellow devs, helped, but the big difference was to have a person in front of me asking: Why did you did this?
I might have had the worst experiences but so far the few times I've had to work on a project that previously was maintained by a solo developer I found the most confusing balls of code.
Indie developers think almost exclusively about if the product is good and sacrifice project/code quality at every turn in order to ship it.
Non-indie devs think almost exclusively about if the code is good, and sacrifice timelines, budgets, and actually shipping something at all at every turn.
I'm talking about myself in both cases 😂
I'm not sure that's an indie thing or a general startup thing. You can be part of a startup team and still be sacrificing code quality and so on.
I've actually heard that in many cases the low headcount and fast pace in many startups can bring about terrible code quality.
Communication. On PR, on reviews, on refactoring, on asking help. The manager of my team says that the difference between a senior and a junior/mid dev, is hardly technical, but on when and how they communicate.
All those things make for a subtle art that is only learn in teams and need to be adapted to each team member, which takes time. It's something that is harder to learn if you jump from project to project (although, there are ways).
I am just speaking from personal POV. >_> .
1.) Documentation: Indie developers don't document. If you do , you are either a maverick or a liar.
2.) Depending on Team: As an indie developer I had habit of soloing on everything. After a certain time it was bit infuriating being told to not do work ¯_(ツ)_/¯ .
3.) Libraries & Licensing : Indie developers tend to use everything available at their disposal regardless of the license involved.. In a company environment libraries have to be pre approved for usage. Plus developers are asked to not use GPL licenses or strict copyleft.
4.) Career Path/ Hierarchy : Indie developers don't think about career paths. While they get to Senior Developers roles faster. Indie developers are out of depth or experience for the Architect or other techno management roles.
5.)Vision: This is debatable. Indie developers don't get big projects or projects which connect to multiple systems. People in teams tend to get to work on bigger projects. But Indie developers can think of an project end-to-end. People in teams usually have work on a small part in a large vision without having access to see how everything wires up. So basically someone who has worked on teams exclusively cannot work on end to end projects.
+1 for point 1 and 2. I found the importance for it when I'm taking over legacy code or doing API integration work.
I was just perusing some code from my brother's project. He is a very effective self-taught developer, but it is interesting to see what falls by the wayside in that environment.... And what jumps out to me is... Dependency management.
His projects have a lot of non-updated dependencies, which I feel is one of those things which you'd do based on the culture of a team and not something you'd just "learn" independently.
I know he does update his dependencies from time to time, but not on a regular basis. I know some teams probably have bad cultures around this as well, but I know personally my values around updating dependencies are influenced by the habits of the software teams I've been on.
Most of my personal projects have zero dependencies. Being self taught from an early age on a ZX Spectrum instilled a mindset of wanting to understand and build as much of every project as I (reasonably) can
I've seen plenty of university-trained software engineers leave dependencies non-updated from time to time, myself included. It's a risk-reward and "Is it worth the time?" trade-off, and often the answer is "No it's not worth the time"
Fortunately there are tools like Dependabot that can help with this on smaller projects if you just enable them.
How about flipping the question too? "What skills do developers mostly employed on teams not learn (vs. those who work mainly as indie developers)"
Testing (not just unit tests), complex data migrations (in some cases), communication between teams, security (in some cases), the value of pair programming, knowledge sharing.
This won't apply to all indie devs but it was definitely stuff I battled with before working in teams and stuff I've seen indie dev friends not learn
I am just part time indie worker but I may ask: What about indie open source work? It's nothing where you actually generate income but you do it for DRY, learning, proving and generating a portfolio for future contracts, generating income.
In my open source work I focus a lot on code quality, documentation, review process etc. and this tends to influence my indie work a lot, so I already try to write maintainable code when getting a contract mostly because I don't want to fiddle with messy code when getting a follow up contract and things get complicated.
I think vision of yourself and how you want to work is important here: I want to be perceived as an engineer who delivers high quality (which is why I want to charge the according price).
One thing though regarding licenses: I care if the client cares, otherwise all-in
I've been in both sides, and as an independent or more factual, as a solo developer in a advertisement team I was very happy ignoring a lot of code quality strategies, I don't know how much is this due the lack of the current online communities, and how much was just me being absorb in the glamour of ad agencies and focusing on bells and whistles. But I kind of remember the feeling of no one understanding why the things couldn't be done as the client "demanded", and me faling to come up with the technical argument.
The first thing I learned when working in a more Tech oriented team, in the mid 2000's was to look up for the community to backup my decisions. The moment I start going to tech conventions and reading in forums more about empathy with fellow devs, helped, but the big difference was to have a person in front of me asking: Why did you did this?
I might have had the worst experiences but so far the few times I've had to work on a project that previously was maintained by a solo developer I found the most confusing balls of code.
Adding to all the excellent points already made:
Watercooler chat ;-) but we learn that here at dev.to :-)