DEV Community

Ben Halpern
Ben Halpern

Posted on

What skills do career indie developers not learn (vs those employed mostly on teams)

Looking forward to the discussion.

Top comments (17)

Collapse
 
ryanflorence profile image
Ryan Florence

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 πŸ˜‚

Collapse
 
andreidascalu profile image
Andrei Dascalu

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.

Collapse
 
xanderyzwich profile image
Corey McCarty

I've actually heard that in many cases the low headcount and fast pace in many startups can bring about terrible code quality.

Collapse
 
etienneburdet profile image
Etienne Burdet

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).

Collapse
 
karandpr profile image
Karan Gandhi

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.

Collapse
 
steelwolf180 profile image
Max Ong Zong Bao

+1 for point 1 and 2. I found the importance for it when I'm taking over legacy code or doing API integration work.

Collapse
 
ben profile image
Ben Halpern

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.

Collapse
 
jonrandy profile image
Jon Randy πŸŽ–οΈ

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

Collapse
 
intelliot profile image
Elliot Lee

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"

Collapse
 
xanderyzwich profile image
Corey McCarty

Fortunately there are tools like Dependabot that can help with this on smaller projects if you just enable them.

Collapse
 
jonrandy profile image
Jon Randy πŸŽ–οΈ
Collapse
 
derekcrosson profile image
Derek Crosson

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

Collapse
 
jankapunkt profile image
Jan KΓΌster • Edited

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

Collapse
 
javierg profile image
Javier Guerra

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?

Collapse
 
scottshipp profile image
scottshipp

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.

Collapse
 
_manojc profile image
Manoj Chandrashekar

Adding to all the excellent points already made:

  • Negotiation
  • Occasionally accepting consensus (against self-conviction)
Collapse
 
leob profile image
leob

Watercooler chat ;-) but we learn that here at dev.to :-)