In short: no. What you sample from working at a company is processes. The more you see, the more data points you have. But you can make up your own processes on the go.
At Ericsson I saw the nice processes for handling customer bugs by multiple lines of engineers, also about writing product documentation for customers. I enjoyed the pace of quarterly releases, the professional calm of small, few-people offices. At Google I learned how to communicate and work effectively with multiple partner teams, how to maintain mass codebase and infrastructure, apply code-review practices to shorten turnover for distributed teams etc.
Processes used by large companies will differ a lot from processes used by a single-person business though. You seem to have plenty of process experience already.
Organization of codebase, service structure, testing plans etc will reflect the structure of the company. So the examples you see promoted by people working at big tech companies (pervasive use of microservices, for example) won't apply to you.
I would recommend reading Scott Berkun's The Year Without Pants, about how Wordpress.com's org operated - a very bottom-up, self organizing fashion.
Practical advice for working solo
Stay far away from edges
Don't use the bleeding edge. Don't use anything with an edge, actually.
You seem to develop Android in Java, good. Stick to it. No Scala, Kotlin, whatever. They will introduce some impedance mismatch, and every now and then make you loose weeks debugging odd corner cases.
No NoSQL, Rabbit/Active/WhateverMQ, Redis, Kafka, Kubernetes, Docker (ok, Docker maaaaabyeee... but no). These have their place if you have a dedicated infra team (or infra guy) who will spend weeks configuring stuff or debugging deployment issues.
No cloud managed queues, databases, whatever. They will be very expensive. Maybe some actual server instances in the cloud, but 1-2 big irons will take you far.
Yes: PostgreSQL / MariaDB. Learn SQL. No ORM frameworks.
Note: you need to play with the edge to keep professional knowledge up to date. But do it for toy tasks, not related to the critical flow in your business.
Invest in testing
When you are solo and don't have a review peer, tests are your best friends. Unit test what makes sense. Later when you have some flow of money, gear up integration / UI testing as well.
Try to add some continuous integration eventually that will run your commits. But initially just don't forget to run the tests every now and then.
Try to add a server-side component
This is optional, likely no need to worry until 1-2 of your apps get stolen. And, maybe they won't.
If you have a server-side, your app will be harder to just snatch and copy. Ask yourself, what knowledge can I accumulate that will be hard (or at least non-trivial) for others to replicate?
Don't go overly fancy. Have a database and a simple Rest API to serve it. Initially you can deploy manually even.
Release often
Working in the dark for six months to get the perfect polished product is a no-no. Aim to release something in two weeks.
Have a list for bugs, feature idea backlog, in-progress tasks etc. A free private Trello board just works fine.
Do the gruntwork
Often there will be non-inspiring tasks, or bugs to be tracked down. You have to bear with these - working on the fun parts is fun, but most of the work is not very fun, at least compared to all the shiny tech you see on blogs. If you find it fun, ask if it is really essential.
If the anonymous poster pings me (can use robinp@treetide.com), I'll send a free instance of my book Programming Without Anxiety. This will show you the frustrations you would likely meet as a programmer, and help decide if you like that sort. Includes advice on handling them as well.
Special Java tip
As I worked with Java for an extended while, I can dearly recommend IntelliJ Idea. You can go a long way with the free Community Edition. Really makes a difference (I generally prefer mucking around on the command line and vim, but for Java I would die without IntelliJ).
Passionate about building great technology and connecting with people to create positive change. Happy to answer questions about transitioning to tech. Find me on Twitter @lounecl
Disclaimer: My experience comes from ~8 years ago, but ORMs were commonplace even that time. Not sure what improvement happened since.
An ORM framework gives you a false promise: that you can forget (or not even be much aware of) that you are working with a DB, and just continue using objects the way you normally would in your programming language (my experience was from Java).
That is a lie, and lies will come to hurt you eventually. Some specific examples that hurt me back then:
The promise that it is easy (no fiddling with schema, DB connections, whatever). Initial wiring is always a hassle - getting the configs right, getting JPA to register correctly, getting the annotations right. Not as worry-free as expected.
Leaky abstraction. For example, when you commit new objects to the DB the first time, their identity changes (see developer.jboss.org/wiki/EqualsAnd...).
Where are transaction boundaries? If db objects mix with regular objects and get passed around in code, it is easier to loose track of what is committed or not (or when). Usually what you want is doing logic upfront, then having a tight section where you make a transaction.
Limited performance. The ORM can't do as sophisticated query optimization as the DB can.
Unexposed DB functionality. Eventually you might need something from the DB that the ORM doesn't expose.
My choice is having a DB access layer, which exposes high-level operations to the user code, but implements db access using SQL directly. I believe it is a low-friction and clear solution.
I never got the idea with MongoDB and friends. My impression was, a lot of bloggers trying to push this new thing, that would make everything much easier.
Every time I came in touch with something ORM, it only blurred the hole data model, and I'd be looking for a way to migrate this thing into a normalized SQL database.
I grew my database bones with mSQL -> MySQL so my opinion might be colored by that :)
An addition to the company experience (I discussed it offline after writing): if not with colleagues, one should definitely start to build out some IRL social connections. Maybe visiting a meetup, or rather frequenting a local coworking office.
Many times I was accidentally helped out after casually mentioning a problem I have.
nice, I will just add:
take some courses or reading about 'Computational complexity theory' if you have not done yet. It's sometimes difference between good and bad aps.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
In short: no. What you sample from working at a company is processes. The more you see, the more data points you have. But you can make up your own processes on the go.
At Ericsson I saw the nice processes for handling customer bugs by multiple lines of engineers, also about writing product documentation for customers. I enjoyed the pace of quarterly releases, the professional calm of small, few-people offices. At Google I learned how to communicate and work effectively with multiple partner teams, how to maintain mass codebase and infrastructure, apply code-review practices to shorten turnover for distributed teams etc.
Processes used by large companies will differ a lot from processes used by a single-person business though. You seem to have plenty of process experience already.
Organization of codebase, service structure, testing plans etc will reflect the structure of the company. So the examples you see promoted by people working at big tech companies (pervasive use of microservices, for example) won't apply to you.
I would recommend reading Scott Berkun's The Year Without Pants, about how Wordpress.com's org operated - a very bottom-up, self organizing fashion.
Practical advice for working solo
Stay far away from edges
Don't use the bleeding edge. Don't use anything with an edge, actually.
You seem to develop Android in Java, good. Stick to it. No Scala, Kotlin, whatever. They will introduce some impedance mismatch, and every now and then make you loose weeks debugging odd corner cases.
No NoSQL, Rabbit/Active/WhateverMQ, Redis, Kafka, Kubernetes, Docker (ok, Docker maaaaabyeee... but no). These have their place if you have a dedicated infra team (or infra guy) who will spend weeks configuring stuff or debugging deployment issues.
No cloud managed queues, databases, whatever. They will be very expensive. Maybe some actual server instances in the cloud, but 1-2 big irons will take you far.
Yes: PostgreSQL / MariaDB. Learn SQL. No ORM frameworks.
Note: you need to play with the edge to keep professional knowledge up to date. But do it for toy tasks, not related to the critical flow in your business.
Invest in testing
When you are solo and don't have a review peer, tests are your best friends. Unit test what makes sense. Later when you have some flow of money, gear up integration / UI testing as well.
Follow this Git branching model
Using version control is mandatory. This works fine in practice: nvie.com/posts/a-successful-git-br....
Try to add some continuous integration eventually that will run your commits. But initially just don't forget to run the tests every now and then.
Try to add a server-side component
This is optional, likely no need to worry until 1-2 of your apps get stolen. And, maybe they won't.
If you have a server-side, your app will be harder to just snatch and copy. Ask yourself, what knowledge can I accumulate that will be hard (or at least non-trivial) for others to replicate?
Don't go overly fancy. Have a database and a simple Rest API to serve it. Initially you can deploy manually even.
Release often
Working in the dark for six months to get the perfect polished product is a no-no. Aim to release something in two weeks.
Have a list for bugs, feature idea backlog, in-progress tasks etc. A free private Trello board just works fine.
Do the gruntwork
Often there will be non-inspiring tasks, or bugs to be tracked down. You have to bear with these - working on the fun parts is fun, but most of the work is not very fun, at least compared to all the shiny tech you see on blogs. If you find it fun, ask if it is really essential.
If the anonymous poster pings me (can use robinp@treetide.com), I'll send a free instance of my book Programming Without Anxiety. This will show you the frustrations you would likely meet as a programmer, and help decide if you like that sort. Includes advice on handling them as well.
Special Java tip
As I worked with Java for an extended while, I can dearly recommend IntelliJ Idea. You can go a long way with the free Community Edition. Really makes a difference (I generally prefer mucking around on the command line and vim, but for Java I would die without IntelliJ).
Why do you recommend avoid ORM frameworks? I thought they were commonplace
Disclaimer: My experience comes from ~8 years ago, but ORMs were commonplace even that time. Not sure what improvement happened since.
An ORM framework gives you a false promise: that you can forget (or not even be much aware of) that you are working with a DB, and just continue using objects the way you normally would in your programming language (my experience was from Java).
That is a lie, and lies will come to hurt you eventually. Some specific examples that hurt me back then:
The promise that it is easy (no fiddling with schema, DB connections, whatever). Initial wiring is always a hassle - getting the configs right, getting JPA to register correctly, getting the annotations right. Not as worry-free as expected.
Leaky abstraction. For example, when you commit new objects to the DB the first time, their identity changes (see developer.jboss.org/wiki/EqualsAnd...).
Where are transaction boundaries? If db objects mix with regular objects and get passed around in code, it is easier to loose track of what is committed or not (or when). Usually what you want is doing logic upfront, then having a tight section where you make a transaction.
Limited performance. The ORM can't do as sophisticated query optimization as the DB can.
Unexposed DB functionality. Eventually you might need something from the DB that the ORM doesn't expose.
My choice is having a DB access layer, which exposes high-level operations to the user code, but implements db access using SQL directly. I believe it is a low-friction and clear solution.
Besides, writing huge joins is fun!
I never got the idea with MongoDB and friends. My impression was, a lot of bloggers trying to push this new thing, that would make everything much easier.
Every time I came in touch with something ORM, it only blurred the hole data model, and I'd be looking for a way to migrate this thing into a normalized SQL database.
I grew my database bones with mSQL -> MySQL so my opinion might be colored by that :)
Nice comment, there are a lot of great advices in there!
Thanks Jan!
An addition to the company experience (I discussed it offline after writing): if not with colleagues, one should definitely start to build out some IRL social connections. Maybe visiting a meetup, or rather frequenting a local coworking office.
Many times I was accidentally helped out after casually mentioning a problem I have.
nice, I will just add:
take some courses or reading about 'Computational complexity theory' if you have not done yet. It's sometimes difference between good and bad aps.