"Just Hire More Devs!" | Project Feline Devlog

Comments · 1.6K

• RA

  @RaymondCripps · 1 year ago (edited) · pinned

  MERCH: <a href="https://store.raymondcripps.com/">https://store.raymondcripps.com</a><br>Support me on Patreon: <a href="https://patreon.com/raymondcripps">https://patreon.com/raymondcripps</a><br><br>Thanks everyone for being so patient. This episode was by far the most painful to make, but I&apos;ve learned things I would have never imagined when I started this game. I might prefer solo dev, but the unyielding community encouragement and support has kept me going when I felt like stopping and for that I will always be grateful, even if I may outwardly seem withdrawn.<br><br>I appear to have caught the attention of some &quot;professionals&quot; with my conclusions, who take offense to the idea that other devs are untrustworthy while at the same time criticising me for being too trusting. But it just goes to show, as the title suggests, it really isn&apos;t as simple as &quot;just hiring more devs&quot; when you become aware of the expensive overhead required to manage more devs, yet alone pay them. Such overhead, or awareness of such, isn&apos;t a luxury afforded to most indies.<br><br>Nevertheless, my point is if everyone took personal responsibility for their work and &apos;washed their bowls&apos;, 15-year industry professionals wouldn&apos;t need to be micromanaged in the first place. I am disappointed to see developers have become so domesticated that they expect their manager to wash their bowl for them, even after being shown how. I dislike this attitude for it robs developers of their individual autonomy, discourages initiative, and undermines trust. I value individual autonomy because, evident by the conclusion, one developer who washes their bowl, even with no training or experience, can outperform a professional. That is why I would not make a great manager, and have so chosen to continue alone.<br><br>&quot;Every time I try to do things someone else&apos;s way, it blows up in my face. That was my choice, but if we&apos;re gonna do this I gotta go into it as me.&quot;—Saul Goodman<br><br>So, my fellow gamers, I hope this gives an insightful look at the technical and interpersonal struggles that transpire during the development of a video game. Could you imagine this scenario with 100 more people?<br><br>Aspiring solo developers, I hope this devlog gives you the courage to do things your way. Contrary to what the industry says, not everyone is meant to be a team player that everyone just magically gets along with. If you find yourself more comfortable with the torture of doing everything yourself than the torture of dealing with other people, then I encourage you to do it yourself, your way. Wash your bowl. Get the small things right to become the person that could make your project. Working alone is not a badge of shame.

  240

• WA

  @Waffle4569 · 1 year ago

  Pro-tip, always have contractors merge their work into the main branch before the contract is up. It&apos;s on them to make sure that works, and that is usually when most issues are spotted.

  2.7K

• YE

  @YellowKamel · 1 year ago

  Labelling a section in the video &quot;The Merge&quot; because it&apos;s a huge event and not something you do every week is crazy.

  382

• DU

  @DukeCyrus · 1 year ago

  Man, I can&apos;t even imagine how frustrating it must have been for the contractor to cut contact like that. Thank you for pressing on despite all the nonsense!

  1.8K

• SE

  @seanss · 1 year ago

  I don&apos;t think the lesson here is to just &quot;don&apos;t trust other people&quot; but more of a lesson in properly managing and overseeing development... Because at the end of the day, there are certain things that you cannot do yourself especially with a project with this kind of scope and with this kind of artstyle. The fact that development has taken this long and the game still hasn&apos;t had a real level yet (and with each level taking like only minutes to complete) should be an indicator of how long other levels would take to complete on your own, especially when you have to make a lot of them. Couple that with the fact that there aren&apos;t any proper NPCs yet, you still have to make models for the main characters of your game, for the enemies of your game and also have to animate them adhering to the limited animation style you&apos;re going for, and you can see why I&apos;m a little skeptical about the development timeline of this game lol. Its fine to take your time with your game, especially since this is something special to you (cue miyamoto quote here), but you also have to consider what really are your goals for the game, and what you want the future of the game to look like, because without proper direction on what you want your game to actually be, this will be a one way ticket for you to be stuck in development hell. There&apos;s nothing wrong with doing everything yourself, but with the quality of game you&apos;re expecting to release at the end, there will be a lot that you would need to sacrifice (time, quality, sanity, etc.)... Bringing on more people can help you alleviate that sacrifice, but you&apos;d just have to learn to oversee other people&apos;s work better. As what other people said before, code reviews are a great way to catch some of these issue early, especially with the amount of money you&apos;ve spent on manpower. You really should have at least checked what he was working on yourself instead of just checking in on everything at the end of his contract, but that&apos;ll just be a learning experience for next time. I know the tone of this comment might come off as quite harsh or very critical but these are just the concerns of somebody who really wants this project to see the light of day. But at the end of the day, it&apos;s your game and your project, and you should do whatever you feel like is best for you...

  675

• NO

  @noiadev · 1 year ago

  This is why solodev devlogs are important. to show these parts of the journey. People can shout, light torches, and gnash their teeth when a game fails to meet deadlines. But you put these videos out there demonstrating what solo gamedev is like. I can&apos;t imagine the sinking feeling you must have had as you slowly realized what the contractors had done to cut corners and feed your baby a bunch of garbage.

  1.8K

• TE

  @Tesl8n · 1 year ago

  I&apos;m a senior dev at my job, and one of the major responsibilities that&apos;s come from that is mentorship. Having a team of other devs that I&apos;m responsible for helping to build effective code, and being the one to know the standards and teach what they are &amp; hold everyone else to them. I&apos;ve had 6 junior devs over the years, all of varying amounts of experience. Some who have worked in industry longer than I have, some who were fresh out of college, or even still <b>in</b> college. <br><br>One of the things I&apos;ve learned is that, no matter how long they&apos;ve been working or how skilled they are, everyone still has things to learn, and has to acclimate to the standards of a new place. Until they do, 100% of people will cut corners, will rush things out, just because trying to both finish something and to learn a codebase and to learn standards all at the same time is too much. And, that learning is such a thought intensive process, often moreso than just writing some slop that works, that the dev also has to be willing to learn it for any of that to take.<br><br>I think I&apos;ve only successfully mentored 1 person to be able to code up to the same standards I hold my own code. To have someone who has developed to at least my skill level, and then specialized to fill holes missing in my skillset. It took that person around 3 years to get there. It probably took my mentor 3-4 years to get me up to his standards (and every time we talk, it still feels like I&apos;m not there lol). <br><br>All this to say, the mythical man month hits hard, and if you want to work with a team, you have to work with a *team*. Random short term contractors can be nice, can be useful, but to actually get that time investment back, you have to put in a lot of time to get on the same page for how to work together. I sympathise with the difficulties here, and kudos to the confidence in your own ability to work &amp; build a quality code base &amp; game solo

  405

• LO

  @Lobstro · 1 year ago

  You had me in the first half ngl. I was thinking, &quot;Why does the video title make it sound like hiring more dev is a bad thing? It sounds like this contractor is doing a great job,&quot; but then I saw the 2nd half of the video

  1.2K

• SI

  @SimplyWondering · 1 year ago (edited)

  &gt; decided to hire a dev to assist with work dispite skepticism<br>&gt; hires person purely off of on paper qualifications<br>&gt; aknowledges soft skills are hard and relationship management takes work<br>&gt; decides to solve the problem by minimally interacting with new team member so there’s no room for friction<br>&gt; does not merge or otherwise check over code beyond the visual output until after the guy is gone<br>&gt; decides the problem was that contractors just aren’t helpful<br>&gt; proceeds to praise quality of own work without taking a critical look at how he contributed to this situation <br>My guy this is not how you manage people. The reason management is hard is because you cannot just chill and let people do whatever they want you need to enforce standards and keep a good relationship, both are important and both often conflict. <br>As much as you talk about polishing the bowl you clearly did not polish the bowl on soft skills, when interacting with people came into the picture you favored doing as little of it as possible instead of taking the time to work with someone else and make that result good. If you had been working with them you either would have very quickly realized you didn’t like their work and fired them (which would have been hard but important) or you would have set standards they could follow and their work would be up to your expectations. Instead you let there be a massive amount of time for differing expectations to develop and then were surprised when they didn’t live up to what you wanted.

  15

• NI

  @nicosool7169 · 1 year ago

  This is why code reviews are a standard in software engineering. It can catch bugs and prevent technical debts before a feature is considered done. <br><br>It also helps to improve, share and enforce good code practices across the team. Even with that, it is said that a new team member takes 6 months to a year to be fully operational/integrated.

  896

• AU

  @Auroron · 1 year ago

  What is the purpose of using a VCS if you&apos;re not doing any kind of code review or continuous merging into main branch? These mistakes should have been caught super early during some kind of pull request or code review. &nbsp;The deliverables agreed upon were perfect candidates for a pull request and would have uncovered a lot of the problems.

  364

• JE

  @JefryU · 1 year ago

  Mann hearing about the way the contractor handled those tasks sounds seriously scary. Though HOLY COW what is up with those animations on the new gabi model its so cleann!!

  491