My goal for the past two weeks had been to sustain the same work input into Adagia, but refrain from implementing anything new and instead focus on refactoring and maintenance. I'm proud to admit, that I made a big boo-boo. Big A mistake that I can admit was suboptimal, but something that gives me empowerment moving forward.
I hardly wrote any tests until the later half of the second week! All I did was sit in this stir crazy zone of wanting to implement new things (and sometimes sneaking it in) and not wanting to refactor code let alone write more tests. I wasn't all in on building and I wasn't all in on refactoring/cleaning. I was basically just unproductive.
What held me back? I had this image of how tests ought to look. I'd studied tests by Spatie, Taylor Otwell, and Adam Wathan and I expected to write tests as well as them. But the secret here is that I'm so far from being a senior engineer. How far? I have never started a project with tests from the start. Adagia was my first project with actual tests even though the coverage is minimal.
What happened in the end that allowed me to begin actually writing newtests? Well I stopped holding myself to such a high bar. I thought of how the easiest way to get writing is to not judge how it might be read by others. Might as well take that approach to tests.
Am I going to now spend the next two weeks doing the actual maintenance that I had set out to do? Nah. When the sun falls it's time to go to bed, Likewise I'm flowing with my own cadence of work. For me, even though the amount of refactoring I performed was not up to par, the lesson came in the amount of intimidation I've eroded regarding such work. The end of this week has given me confidence to write tests in tandem while building new things.
After six weeks of building I'll still take a two week building-pause to focus on refactoring. By then what I hope to have is an MVP system for group writing.
Right now the Tribes functionality is so decrepit that it won't even be used by the power user that I thought would use it no matter how shitty it was lol GabrielGreco. When people like jasonleow ask about it I tell them later later.
This is only natural because I never spent actual time and focus on Tribes. in the first building phase of Adagia, I only got to work on it in nooks and crannies of time between making Adagia feel as much like the good parts of 200WAD as I could manage. So if the first six week phase was dedicated towards a 200WAD migration MVP... the next six is an MVP of the first suite of user interactions (aka MVP) original to Adagia.
I want to thank anyone who's read this and everyone who continues to write here. And to anyone reading this in the future I hope it's helpful for your journey.
Lmao well it'll work a different way going forward.
Is that big secret true? Lol aren't there some enclaves where there are senior engineers who would put the smackdown on the team for not beginning with tests??
lmao you know that thing you do when you release a new feature? Where you go through the UI and make sure you can do fuctionality X, Y, and Z without bugs?
Well eventually that process will get really long and so programmers decided to automate it.
abrahamKim Hahah I know. Was just jesting. My tests right now consists of me trying it out in local and staging, and from feedback from users in production. And hoping for the best. Not the best practice for sure, but high cost to speed of implementation in the initial days.
Oh okay! Lol I just remember one time I said something related to databases and you asked wht they were and I thought you had been sarcastically joking and I went along by further jesting and it turned out you were actually asking and then i felt really bad!! lol
I went with your exact way of implementation for years no worries. For me what made me finally bite the bullet and start writing tests is because I hated the psychological effects of me wondering whether a thing had a bug or not. Sometimes a user would come back to me about a bug in software A when I had cleared the day to work on Project B. Eventually it just became too much and also it started lowering my speed of implementation.
I think not writing tests is like staying up late and waking up early. It's fine to do as a college student when you're partying and also getting good grades. Eventually though you gotta start prioritizing sleep. therealbrandonwilson style.
College bit made me thiink of jack for some reason
Lol I know you don't wanna hear this because I didn't wanna hear it before but eventually without tests you'll eventually reach a phase in a project where you can no longer move forward without breaking changes.
abrahamKim i see. Re: this phase you're talking about, what are the parameters to look out for? Is it dependent on how large the codebase gets, how many bugs with every deploy, etc?
When you don't possess confidence in old features breaking on each deploy. Features breaking should not be a regular thing and be a real doozie. If you don't have tests from the start though that is the baseline so it's hard to turn back the tide on such lol
OK... hmm would having a staging site solve that? Deploy to staging, see which features break, fix. All without user knowing. But granted, some edge cases might be missed even with that...
Lol I went through the same frame of thinking too! I put up a staging site and thought that would be good enough. But then you still have to go through the staging site and manually try every user interaction.
Eventually it'll take too long to do that manually so I started slipping and then that's when the bugs come lol
GabrielGreco
jasonleow
And Tribes works! That's all that's required at this point.
Is that big secret true? Lol aren't there some enclaves where there are senior engineers who would put the smackdown on the team for not beginning with tests??
Well eventually that process will get really long and so programmers decided to automate it.
I went with your exact way of implementation for years no worries. For me what made me finally bite the bullet and start writing tests is because I hated the psychological effects of me wondering whether a thing had a bug or not. Sometimes a user would come back to me about a bug in software A when I had cleared the day to work on Project B. Eventually it just became too much and also it started lowering my speed of implementation.
I think not writing tests is like staying up late and waking up early. It's fine to do as a college student when you're partying and also getting good grades. Eventually though you gotta start prioritizing sleep.
College bit made me thiink of
Eventually it'll take too long to do that manually so I started slipping and then that's when the bugs come lol
just start writing tests!! you won't regret it