One of the strongest heuristics for career progress (and personal growth) is how readily you change your mind about things. After all, everybody's ...
For further actions, you may consider blocking this person and/or reporting abuse
I thought the main issue of monolithic solutions was composability and that I could solve it, but it turned out the real issue was complexity. I learned that it's better to have simple primitives which work in any context than a complex solution that does that all only in its own context.
I had written a monolithic fetch module for solid-js, aimed at bridging the gap between createResource and tanstack query, but the composability was the second biggest part after caching. The complexity was a foot-gun, so only few people used it.
So I started breaking it up into case-agnostic primitives that can be used for more than just fetch and leave the composition to the developer.
I will be graduating school after few months. I have decided not to join a college immediately after it. I'm planning to stay put for one year to have my life in order and decide career options. This is something I changed my mind about recently.
What do y'all think? Good decision?
In my experience, when people take a break it's really hard for them to go back to studying/learning/working, I recommend that you get a job or something so you don't loose the habit of working, that's what I have seen, maybe your case is different
So much this. After high school, I joined the army (to get the college benefits). When I got to college three years later, it was really hard to get back into the swing of academic life.
Go to college. You don't have to know what you're going to do right away -- try different things. Or as they say, "fuck around and find out." You can knock out a bunch of general ed class requirements while figuring out what you want to do for a living.
Yeah I can relate to what you are saying. I'll keep working on projects to not get diverted 🙋🏻♂️
Might as well get your gen-eds out of the way while you're deciding IMHO. When I was in college a few years ago, they said 80% of students change their major or minor during college, so it's not super important that you know exactly what you want to do with your whole life before you get there, and if you're trying to decide, it's helpful to have professors around to talk to who've had careers in a variety of industries and fields of study.
Also, be sure to check all your scholarships--a friend of mine in high school was an LDS, so he had to take two years off, and he ended up losing most of his scholarship money because it was earmarked for graduating seniors starting college immediately.
Just my two cents.
Yes. Take your time and get it right, there's no rush. 👍
NoSQL was such a pressure-cooker when it was hyped. It was a real relief for me when I settled into a mindset of "Okay, there is definitely a place for this technology, but I am so cool not adopting this."
I think the way the MEAN stack was marketed towards bootcamps and junior developers was a really bad thing for the ecosystem. It really was marketing too. Where were all the PEAN stack advocates. Somehow if you were in the full-stack JS ecosystem you also got shoved into NoSQL.
As for my own answer — hard to articulate, but I'd say I've changed my mind about any project management approach being inherently good or bad, and I just focus a lot more on the tweaks to get the right fit for the team and the tasks at hand. That's sort of vague, but I used to take harder stances from time to time which I just can't see myself doing anymore.
As a former PM, I've got agree with you re: methodologies. It's unfortunate that there are a lot of places that force everything into a single methodology, when in reality, each project should demand a certain methodology. When you've got a vague scope doc, unrealistic promises from sales, and high turnover in your dev team, clearly traditional waterfall methods are the way to go, right? (I'm not specifically calling out any one agency here, but I am definitely thinking of one in particular.)
I switched to PM after about three years as a dev, so I didn't learn the lesson until after I became a PM, but the thing that devs should be aware of is to never have strong opinions on approaches to solving a problem. There is no one-size-fits-all-solution and there's more than one way to skin a cat.
For me it was the individual contributor vs management track. Previously I was adamant that I wanted to stay as a developer, be one with the code and spend my days designing elegant solutions to complex problems. However, more recently I've noticed the positive changes that a good engineering manager can have and I've now retracted that opinion and am more open to the idea of becoming a manager.
I used to consider that Back-end was "the real staff" while web development (front-end) was the easy thing. I struggled to get the master degree and I used to think in these terms of "I've studied to do back-end things, i should do this" .
I've been gradually changing to pure front-end development for the last years.
I'm happier now.
Too many things over the years. Being comfortable changing your mind shows (I think) that you welcome other ideas and suggestions and that you listen and take them on board.
In my language we speak: measure seven times cut once. It's important planning your actions or algorithms and develop but not both or reverse order in same time.
Thanks for your post, especially your examples which I found funny compared to my own change of mind.
When I first heard about noSQL I found it terribly wrong, just like I did when I first heard about using JavaScript in the backend, and just like I did when I ... started to use SQL!
So long ago that I forgot in the meantime, but there have been many technologies that I later came to embrace and even love, or at least dispise less. In the end, they are nothing but tools anyway to make some electronic devices to some arcane process to produce some useful output.
I even remember writing a parody about SQL for its unintuitive behavior of NULL, calling it the "NON language" where everything that ever has the slightest contact with "NON" turns itself into "NON". Later, I got to like SQL for its compact syntax that can fit a lot of complex logic into a single line of code.
I also remember being quite skeptical about computers and programming when my cousin first showed me some code and its disappointing output. We were both kids back then.
Funnily, opinions can go on a round-trip much like major technological trends. Assembly machine language vs. high level human readable languages (or even prompts to a chatbot that would write the actual code), separation of content and style vs. the comeback of functional CSS class names in Tailwind CSS (that never went away, see Bootstrap) which, of course, reminds me of the hard time changing all of my
<font color=red>to<span class="red">to<span class='site__article--main-article'>to ... (and so on) over the years.I used to be very skeptical about Windows, or graphical point-and-click interfaces in general (everything used to be so quick and simple just keeping my 10 fingers perfectly positioned above my mechanical keyboard?), same with CSS (why would we want to move markup away from where it's going to be applied?). Now I use a lot of the tools together or when they seem to fit, still typing on a mechanical keyboard most of the time, using the
vieditor forgitand configuration files, but a complex IDE for coding, and web browsers with their developer tools which are hard to imagine without a graphical context.I remember a few technical tools that I liked from the start and still do, including Linux, HTML, and the GIMP.
Concerning people, we can be wrong about others, we can change our mind, and we should. There is love at first sight, there are deceptive characters, impostors, or people getting corrupted by power, money, or grief. On the other hand, as you mentioned junior developers, some people have a weak start or a bad day but make up for that in the long run. So I would never judge anybody based on the first impression either.
Just in time compilation and garbage collection. Back in the late 90s/early 2000s when I felt like a C++ expert and computers will still slow enough that performance in everyday code mattered, I thought it was an anathema to waste all those resources on memory graph scans, interpreting bytecode and compiling on the fly. I couldn't have been more wrong. Managed memory and JIT-compiled code is today often better performing than precompiled native machine code.
I used to overestimated technological progress, I think I might have switched to underestimate it... (or not... :-D )
I changed my mind about writing perfectly clean and fast code. Everything is a tradeoff.
Nice post cover 😄