[-] yournameplease@programming.dev 1 points 1 month ago

Are you familiar with neocities (geocities revival thing)? It's not anti-scripting but it may scratch your itch.

[-] yournameplease@programming.dev 6 points 3 months ago

If your school has Hackathons, try to do those, ideally with friends. The atmosphere is honestly a bit horrible in my opinion and you may get instant imposter syndrome, but it gives you a project to talk about.

0

Referring more to smaller places like my own - few hundred employees with ~20 person IT team (~10 developers).

I read enough about testing that it seems industry standard. But whenever I talk to coworkers and my EM, it's generally, "That would be nice, but it's not practical for our size and the business would allow us to slow down for that." We have ~5 manual testers, so things aren't considered "untested", but issues still frequently slip through. It's insurance software so at least bugs aren't killing people, but our quality still freaks me out a bit.

I try to write automated tests for my own code, since it seems valuable, but I avoid it whenever it's not straightforward. I've read books on testing, but they generally feel like either toy examples or far more effort than my company would be willing to spend. Over time I'm wondering if I'm just overly idealistic, and automated testing is more of a FAANG / bigger company thing.

[-] yournameplease@programming.dev 9 points 5 months ago

You can start by using plain, semantic HTML and grabbing a classless CSS with a license you like. (Check out this list.)

It's good enough for a simple app or site, and it's honestly impressive how good something can look with just this. It's the "plain t-shirt and jeans" of web design.

[-] yournameplease@programming.dev 3 points 6 months ago

Great advice, you two. Have a bunch of kids and teach them APL, Actionscript, and Autohotkey. On it!

:)

47

I have about 2 YoE, and I'm sure this changes with more experience.

I often hear this idea online that programmers should follow "just-in-time" learning, meaning you should prefer to learn things you don't know while on the job. ( The way some people talk about it, though, it sounds like you shouldn't dare spend a single minute learning anything new outside of your 9-5. )

This seems generally reasonable advice, especially for simpler things that take a few hours like learning a specific language feature, library, or similar. But when I lean too much on this JIT learning, it feels possibly detrimental.

Many times I do something big and new to me, say, deciding how to approach auth, microservice architecture design, automated testing, containerization, etc., I end up making a big decision after a few hours or days of cursory reading on documentation and blogs, only to come to regret it some months later. At that point, maybe I'll slow down, find a book on the subject, read it, and think, "Oh, darn, I wish I knew that N months ago." It certainly feels like spending more time learning upfront could have avoided mistakes due to lack of knowledge. Though there's no way to go back in time and know for sure.

I'm not asking about any area listed in particular. I feel like, for all of those, I've learned more in the time since, and would probably avoid some of my prior mistakes if I did it again. The question is more: How much do you subscribe to this idea of just-in-time learning? And if you do, how do you know when you've learned enough to be confident, or when you need to slow down and learn in more depth?

[-] yournameplease@programming.dev 1 points 6 months ago

Thanks for the response. I agree that the project's big boss has an impressive ability to BS on the greatness of our project, and it may be enough to push the project past the finish line.

It seems you put a lot of weight on the project's "triumph." If the project fizzles out or fails spectacularly, does that not make you more of "the fool who couldn't do it and didn't know when to quit?" I don't think I'd hold it against my coworkers for leaving if they think it would improve their situation. (And doesn't a sound project plan account for the fact that you may lose people every so often?)

Interesting note about small job market though. I only have a ~20 person IT department without much churn so it feels quite small to me still. How do you see this reputation spreading? Just the diaspora of former coworkers is wide enough that most/many companies tend to have someone who knows / has heard of you?

[-] yournameplease@programming.dev 2 points 6 months ago

Yes, considering it as a paid education always helps. I don't really think of anyone here as a mentor, so I usually have to study on my own to learn what I need, and I still tend to regret most design decisions I make. And there's just that looming feeling that everything I've worked on is ultimately worthless. But I guess all of this is just part of the software development job, ha.

Interesting that you say jumping damages the personal image, since it seems what most others here advocate. This job gives me good perspective, so I still wouldn't want to go elsewhere without convincing myself that it's a meaningful improvement.

[-] yournameplease@programming.dev 2 points 6 months ago

I agree that I tend to enjoy my personal projects far more than anything at my company. My typical problem is that I burn out quickly once I get really into anything long term. And frustratingly, I tend to want to work my own projects most when my work gets most stressful.

I guess it's just hard not to get attached to something you spend so many hours working (and unintentionally thinking) of. But this sounds wise advice.

[-] yournameplease@programming.dev 1 points 6 months ago

My project fits both. It took about a year before this was shown to more than a couple business users. But we still had Scrum sprints and pressure to get items done at the sprint, even with no deployment or demo for feedback.

[-] yournameplease@programming.dev 1 points 6 months ago

Sadly not. This post comes after my frustration of this same exact meeting, and now the project is delayed by a nebulous 2-4 (or more?) months. Sounds like I may actually be moving off of it temporarily since it's been pushed so far back, to another, slightly less ambitious project that's getting started. To be determined if I can help this next project go much better.

A big fear I had was that a failed project would reflect poorly on me looking for jobs. But hearing how common dead projects are, I guess it's no surprise that many people go so long not seeing a successful one.

[-] yournameplease@programming.dev 1 points 6 months ago

We are reasonably consistent with estimates, but there's this hidden assumption that 1 point equals 1 developer day. So even though we consistently get 20-25 points done per sprint, we typically cram more items to meet that 30 point threshold.

Oh, and of course you may end up dragging items sprint to sprint if they don't get finished.

[-] yournameplease@programming.dev 3 points 6 months ago

I admit it's possible the project "succeeds" and gets out the door. My prediction in that case is that we limp along and eventually give up after maintaining it for a while.

I only work my ~40 hours a week. When I did much more than that, I think my output went negative.

I think I learn a lot, at least. The project has a more "modern" stack than the company's other main product. And management/leadership being hands-off means I make a lot of big decisions myself. Many bad decisions, but at least I learn what not to do next time.

[-] yournameplease@programming.dev 5 points 6 months ago

High on all fronts on that test, which does not surprise me. Though what you describe sounds worse than what I have. I'm just generally tired and pissed off, despite thinking myself a normally happy guy.

I'll take this as my nudge to put my casual job search into overdrive.

41

Scene: Surprise meeting with the project owner 0-3 days before the go-live date

"Hey team, the business and I have decided to postpone the project release by n=1-3 months because [they aren't ready for it / it isn't finished /regulatory reasons]. And since we have some extra time now, we can tie up all the loose ends on this project (i.e., 'we've added n+1 months worth of backlog items to the MVP')."

I'm still a greenish dev, so maybe this is normal, but I've had the same story going on for over a year now, and it's really starting to burn me out. In the beginning, I was optimistic. Now I just hope for the project to fail, or me to get off somehow, but this thing just won't die.

Anyone with experience on similar projects able to share words of advice? Do they ever end up working out? Seems there's a death spiral, since we are always rushing to a deadline, forgoing tests and quality but never cleaning up our mess because we're already behind. Yet I somehow feel like I'm the crazy one for thinking this 6-month "quick" side project turned 2+ year half-rewrite will have trouble meeting it's Nth deadline.

view more: next ›

yournameplease

joined 6 months ago