From my personal experience, are you still writing things the same way you were six months, a a year, two years ago?
I look at code I wrote a couple of years ago, and not only can I identify how I would write it differently, I can identify /why/ I would write it differently - both what technique, concept, or methodology I have since learned, and how that would make the code better.
If you cannot, you have probably plateaued, like I did for a (far too long) while.
I noticed yesterday that I've implemented the same type of CRUD API call in 3 different ways in code I've written in the last 2 years. And I can see why I did that and what I was trying to optimise for in each case. I'm sure I would write it differently now, but would I write it better? I have no idea what "better" is any more. Faster? Easier to read/maintain? More loosely coupled? All of these?
I spent two weeks building a Go version of Webpack last month because it was either that or implement Webpack because the Vue components we're writing needed unit tests. Was that wise? It works fine, I don't have the gajillion shitty dependencies of Webpack, and it compiles, bundles, uglifies and minifies our entire Vue front end in <200ms but is that a good thing? Was I an idiot reinventing the wheel, or was I wise avoiding exposing us to the insanity of npm? When it needs maintenance in a few months and I have to spend a few days fixing it, is that time wasted, or have I saved time because every time Webpack updates a version everything breaks and we don't have that hassle?
To me, that sounds like you've hit a ceiling in your current stack, and probably workplace, and lack examples of people around you to learn from. What the solution to that is depends on your situation. Change of workplace? New career direction? New hobby?
> I have no idea what "better" is any more. Faster? Easier to read/maintain? More loosely coupled? All of these?
"It depends." As a gross generalisation, most juniors optimise for their bug-bear of one of these at the expense of all of the others. Most mid level devs try to balance them out, and hopefully, most seniors pick which ever is appropriate for the task at hand, with an eye on the long term consequences of their design - if there even is a long term consequence.
Re webpack replacement; Given the amount of time I've wasted dealing with webpack and it's madness, I'd back you up and say it's probably a net win - as long as it's documented enough to avoid the bus factor. It's not like golang is some esoteric language where it's impossible to find devs for.
P.s: I want to clarify here that I'm not necessarily a good programmer, I've just spent enough time stuck as a niche programmer & probable expert beginner and fighting my way out of it that I recognise the patterns. I'm probably a better study of dev behaviour than actual dev.
being the only senior in a tiny startup, I'm definitely lacking examples. I think I'll look for a Go expert freelancer to be that, when the startup is making enough money. Thanks :)
Well you could separate out any internal parts that can't be shared (secret keys etc) and put it out on a service like github. This might help you understand where you are at in terms golang and building something generically useful like webpack.
I look at code I wrote a couple of years ago, and not only can I identify how I would write it differently, I can identify /why/ I would write it differently - both what technique, concept, or methodology I have since learned, and how that would make the code better.
If you cannot, you have probably plateaued, like I did for a (far too long) while.