I remember playing it on newsgroup. Good format (with threads and subthreads) and people using correctly actual convention.
Too bad I don't see a running game anymore.
By chance!
I was working in a company that needed a mail templating that could send a large amount (yeah... I learned it was spam alike after)
And one of my coworker came with a solution of programming by actors with Akka actors, based on scala.
So to help this coworker maintaining and evolving this application, I learn the language and the concepts under the language.
Now I chose my current job partly for the language (and because there is a strong connection with open source contribution)
Really, for my job, it depends on the subject. Next feature: the CTO (small structure, so he has the PO cap). Small library dependency to add in our project, the dev that need it. Big refactoring: the one that had the idea validated by the whole team (to be sure it's the path we want to take). Process/documentation: a team specific meeting.
Usually, small nits to change to sustain all team members.
For current next big feature, it's the fourth proposal and we don't agree yet. So was have more proposals to come.
I don't understand why "title"s are so partitioning?
Obviously, the PO is accountable for the user stories, but they are not to write them all by themselves.
Let the PO decide what is the next big feature, then pair them with a dev to split into manageable stories.
Such stories will be then smaller and still have to be split in task. But at least, the user story will be small enough to be develop as is.
PO will have the last word about the big picture and the details (user facing) but the means are in dev hands.
I have a graveyard full of such personal projects.
In another hand, if you are still maintaining this project, it can be interesting to refactor it and show your process doing it. It can be a great way to show actual useful skills for a future interview or, at least, train to do so before actually using it in a real production project.
Refactoring to a state of the art state while the project is still under development and shipped can be a valuable skill to train and show.
My opinion: first versions of an app is often written as PoC, without any test. It requires real data (file, db, working external API) and only "works".
Because at that time, we (developers) know what should be done and how.
Then come users who will define their own stories, where TDD is the best but... it is now hard to test.
Congrats!
From the landing page, I miss some information:
* will it be always free? (I guess not)
* what do you do with my email? (Only for login, or do you sell it)
* will my data be mine or do you own it?
I understand that it is a MVP, but I cannot put job real data without warranty.
Indeed, as backend developers, it is hard to show something attractive.
If you really need a portfolio, I suggest:
* A classical project (CRUD for website, small cli, etc)
* A not so classic project (choice is up to you) with documentation about the architecture, a clear API (rest for website, man page for cli, interface for library, and so on...)
Each project should be well tests covered, should have good automation (github actions are free for public repositories for instance) and easily run locally.
Bonus point if you can use language/libraries/framework from your future employer in a way that is correct but different from their usage. (Hard to know before)
What I understand: a big project divided in 4 parts. Each part is owned by a team of 8-12.
A teach lead by team seems fine. Seconded by senior that help mentoring.
How do you really define a tech lead? How did your tech leads become such? Do they really need to carry their whole "part" or only be an technical interface between their team and the others?
The real questions are not a bare number, a simple heads count. But a whole definition of a "title" and what this title really mean in your environment.
Experience may vary from context.
In a former company, I had the "tech lead" title. I had the technical responsibility of a team of 8 members (including me). I took the final decision about architecture, implementation, API and other workflows to the outside of the team. We carried 40+ projects (real number is around 60). It was exhausting!
In my current company, the "tech lead" is a non-sense, we are autonomous and we trust each other. We need the CTO to define clear priority list he wants to see happen. Then, usually, someone is the "feature lead", the person who decide the architecture, the order of the different tasks to implement, who manages the attribution of the mentioned tasks.
Currently, this feature lead is the more "junior" of the team. Because he took time to understand the feature, he benchmark and test the different solutions. Obviously, as other team members, I challenge his decision about details. But the final decision remains his. And I blindly follow his final word. (Even on those I personally disagree). It's not a matter of ego (I'm more experienced) or of knowledge (I teach him a lot). But really, about the feature and the time invested to understand the feature, the needs and how to integrate it in our code base.
And today, with your question, I realized that I was pretentious. I thought because I follow each pull requests, I discuss with him about the architecture and the feature, I will be able to lead the feature from a day to another. But the reality is: I was miserable. I failed to recognize simple errors. I failed to know where to look when something bad happen (during test phase). All of that, because I was not the feature lead this time and I didn't take as much time as him to really understand the feature and its components.
With your question, I realize now that he really did a great job, and I am happy to work under his lead (during this feature at least).
I repeat myself: The "tech lead" is just a title, what matters is how you define it and how this tech lead endorse the role.
PdfTk-Builder: a GUI for pdftk for windows. My partner is stuck with windows for work (and not really a techie) so, this is perfect.
Youtube-music: love vanilla YouTube music, but automatic pauses break my flow and ads are very aggressive. This electron port allow me to have an AdBlock and remove pauses. Bonus, I can use my media keys directly from my keyboard.