I need some advice in how to be a developer in a company.
Now I’ve never worked in business with an established development team and now I am the team. I dropped out of school and became a salesperson that led me to position I’m in now.
How do developement teams usually handle workflow, deployment and project management?
Is there something I need to do / have in mind in case we expand to another developer so I don’t come across as a complete idiot?
Good git commit messages, feature branches, some light scrum maybe. But I’d say, if you document what you’re doing, worry about that when the team expands.
Am basically in the same position, am only embedded dev in my team, and there are no higher level guys working here yet, only hardware guys. We do have a PM tho who manages scrum with Jira, so there’s that.
I just try to come up with good scrum tasks and git commit messages for myself lol.
How do developement teams usually handle workflow
Poorly.
deployment
By overcomplicating it. In the tech industry, you spell that K-U-B-E-R-N-E-T-E-S.
project management
Start with Jira. After you get the developers using it a little bit, mandate that everybody else use it (gold star if 100% of your janitorial staff use it regularly), link it with Confluence, depricate all other forms of documentation.
Next, hire a Project Manager who insists on measuring productivity by burndown charts rather than development velocity, completed milestones, or happier customers.
Is there something I need to do / have in mind in case we expand to another developer so I don’t come across as a complete idiot?
What I described above is what a lot of companies do. Don’t do that. The “development workflow best practices” are so badly handled in many places that they’ve become a joke, and destroy productivity.
Company policy is going to affect your workflow quite a bit, especially regarding deployment. Some places have scheduled maintenance periods due to SLA agreements with customers. Some companies cater to free users who have no expectation of stability and they ship every commit immediately.
Your business objectives, not the hotness of a particular tool or management style, should dictate your process.
Generally speaking, letting developers pick their own tools works best, and the biggest barrier to doing that is often political, not technical. Micromanaging managers do more damage than bad tooling, in my experience.
With a small/non-existent development team, establish documentation and testing as critical parts of the development process. Sooooo many places treat that as an afterthought and only try to shoehorn it in once the lack of it becomes a problem. It’s easier to build that into the team culture in the beginning than get people to start doing it later.
If possible, use an internal open source model. Passwords and keys will be a problem for Security and Compliance reasons, but everything else benefits from other developers being able to raise issues and make improvements. As teams grow, that becomes important, especially if you go with a microservice model.
Discourage meetings, but do everything possible to facilitate impromptu “rap sessions”.
Lmao. I’m starting to experience this.
Everyone screams “CONTAINERS” while investing an insane amount of time and energy in a platform that already does what something else does.
Blue/Green deployments == Containers 
@imhigh.today Makes a lot of really great points, OP. Despite them potentially being inebriated
just try to come up with good scrum tasks and git commit messages for myself lol.
I think this would be a step in right direction. so far it’s just been all changes have the same commit messages …
With a small/non-existent development team, establish documentation and testing as critical parts of the development process
This is something I’m trying to establish, but again little to no experience with TDD or any kind of testing really.
Does anyone have a good resource to get into the TDD mindset ?
Learn how things can be done, find a way of doing it which works for you and the project. If he thinks you’re an idiot for not doing it like everyone else, then I’d say he’s the idiot for not accepting that there’s more than one solution.
Can only agree. If nothing else, get used to using git. Document what you do short and precisely. Most IDE’s have reasonable built functionality for this.
Project managers can easily be the make/break factor in a project. I’d like to have one that has several years of developer experience. My point of view, how can someone lead a project, when they have no idea how it can be done.
Indeed, even got fired more than once for telling this type of manager to piss off.
Very true, damn meetings piss away so much time it hurts.
Containers are loved and frowned upon, but they do have their applications. I personally like to use them when I’m developing a personal project, easy and local testing can be done. Do agree with what several have said about containers and kubernetes, it’s not the answer to everything, but the approach towards a larger project changes considerably when viewing it thinking monolith or micro services.
At the end of the day, don’t do what others do or what others say you should do, be aware of what’s the current trend, how it works, what its purpose is and from there discover options that fit into your workflow and your way of doing things. Even the best system can be disruptive/restrictive if it doesn’t work for the individuals in the team.