• 0 Posts
  • 7 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle
  • No problem 🙂

    Interestingly enough, these days I have been thinking about resuming my experiments within game development. It’s not a field I am super experienced in, but just for the sake of knowledge sharing…

    I started a small project in MonoGame with C#. It is a low~ish level framework, just as I wanted, because I wanted to avoid learning a full-blown engine (such as Godot, which I tried before going with MonoGame). Not that I am recommending this particular track for your situation, though, but based on what I am doing in MonoGame, I think it could be a good way for you (if you chose this track) to be pragmatic (making something) while still forcing you to learn programming. The framework still takes care of some things such as the game loop.

    I also created an account in Exercism, one of the communities I mentioned before, because I wanted to mentor someone and they offered this posibility. Whereas I didn’t find exactly what I was looking for, I found the website to be quite pleasant to use, so I am slightly more inclined towards recommending that you consider using it 🙂


  • You are starting a journey which is not short, that will be full of amazing things but also frustration. You also mentioned in a post that you want to create a videogame like EU4 and HOI4. I think that is a good goal to have, but also a quite ambitious one.

    In my view, you should focus on finding a way to learn programming that keeps you motivated and prevents you from quitting early in the process. Choices of programming languages, technologies, platforms and things with fancy names should be done with that in mind.

    So, how to learn programming? I think that you should…

    1. Find some materials you find yourself comfortable with. Those materials might be reference books, video tutorials, guides, online courses or anything else. You need to find what you like to use as a reference.
    2. Start making things as early as possible, and complete them as often as possible. In other words: start simple, small projects that you can complete and start them often, don’t wait until you can implement a quicksort to write something you are interested in writing. Maybe even don’t write a quicksort at all. Focus on doing stuff that interests you while making you learn.
    3. Find humans that you are comfortable with to share your progress with, ask and learn from. This community may very well be that group of humans, but you can think of others too. Maybe some friend, maybe someone you know online. This is useful because other people can make your learning process faster and, importantly, less frustrating. Other people can also help you with the two previous points in this list: finding materials and giving some ideas for new activities or projects.

    So, where exactly to start learning? I think that you could… (different options)

    • Start learning a programming language, such as Python. Python in particular is easy to learn, very powerful, well supported and has huge community. It will help you learn programming and it will be useful after you have learned. Other languages can also be okay, for instance C#, which is maybe slightly more difficult than Python but it’s a good choice for game development.
    • Start learning a game engine, such as Godot. This way you will need to learn the game engine AND programming in order to do anything, and that’s maybe a little too ambitious, but it is more pragmatic.
    • Find a community, school or similar that can guide you through the learning process and stick to it. I am talking about sites such as https://www.freecodecamp.org, https://exercism.org/ or https://www.theodinproject.com/. I am not recommending any of these in particular because I have no experience with them, just mentioning them so that you know what I am talking about. These communities usually have a plethora of challenges or guided exercises that walk you through learning how to program.

    There are many options, and you will hear a lot of recommendations of what worked for other people. That is fine, but you need to find what works for you 🙂



  • This also happens in the Midsize Companies I have worked for, and also in the Small Companies where management was not technical or had no interest in technical topics.

    I think key factors are:

    • Distance with managers. More is worse.
    • Interest/knowledge they have in technical endeavors. Less is worse.
    • Layers of management. More is worse.

    That said, and whereas the advice might be effective, it also sucks to not be true to your own values. I would suggest to try to be communicative, but maybe don’t become the asshole we all hate. And try to know more about the company on this regard while interviewing. Difficult, true, but include this in the list of factors when deciding which companies to join.


  • I from time to time do something like what you are looking for, I believe. But I also think that it’s going to be difficult to find those “solid specifications you might get from a customer”.

    What I do is to start a project that usually reinvents the wheel, so you know exactly what is needed, and focus on experimenting at different levels as you said: architecture, project management, design, UI, coding, CI/CD, pipelines, quality, etc. You also end up learning a lot about the problem itself.

    For me the goal of those projects has not traditionally be to release something and create the next startup, but to experiment and have some fun. In my last project I also tried OpenFastTrack, which is a tool for gathering requirements and tracking their completion in the repository.

    It was a lot of fun. Maybe this sounds good to you, and the truth is I have been looking forward to collaborate with others with the same approach, to also introduce the “autonomous team” factor to the experimentation 🙂.



  • I think what you are saying is technically correct, but it fails to acknowledge the importance of human emotions. Emotions are involved in everything humans do, and since software is written by humans for now, the act of developing software also involves emotions.

    This does not mean that it should be a emotion-driven discipline or that emotional arguments should be weighted more than other kind of arguments. It just means that everyone will deal with human emotions while developing software, both their own and others’. We can of course manage our own emotions as we wish, but then the question is how do we act on regard of others’.

    My main thought here is that disregarding how others feel about your actions rarely helps anyone. When collaborating with others, we usually aim for getting the most out of that collaboration. That is only achievable if the other person feels safe and welcome. Maybe writing some harsh comments in a code review is not the best way to do that.

    Next thing that needs consideration is that we are all different, and what for one is a small gesture, for other might be offensive. You don’t know everyone else’s personal history, background or experiences, so you don’t know what can negatively affect them. This needs to be acknowledged, particularly when working in heterogeneous groups (ie, people from other cultures). You can ignore this fact, but it will negatively affect the collaboration.

    As with everything else, people can become better at communication and collaborating with others, and still be able to defend your points without being aggresive.

    Why don’t they, then? My first guess would be that this is seen as irrelevant. This is how I do things, how we do things in this industry, learn to deal with it. I don’t think that is a good approach. It does not harm your engineering skills nor the product of your work to be kind to others. On the opposite, it makes their lifes easier. I don’t see a reason why we shouldn’t strive to do that.