How do I know I’m not developing fast enough?

I compared to a lot of students at my university, I find myself working the opposite - documenting and planning first, then coding.

Everyone at my school seems to be hitting the keyboard and just hanging out solutions in a day for our labs.

Even at my internship, I sometimes found myself staring at existing code bases for a week before I could even do anything.

Is this normal? It’s so hard to know how well I am doing when it feels so hard to measure...I mean, even with all the tools of git etc, should I even be measuring?

It's totally normal imo. I'm the same, thinking more than coding which will result in optimized and "good" code. I think you're on the right way.

But sometimes you gotta jump right into stuff. So don't always limit yourself.

Don't compare, everyone has their way of doing things, for better or worse.

Some plan ahead, this usually makes for maintainable projects.

some code first and make spaghetti that can't be undone, don't be this guy!

and some can plan while coding which gives the base you need but there's usually some spaghetti on top.

As @C0D4 said, it really depends on the person.

I, personally, can't plan ahead easily because that's not how my brain works (required to do that at my study and I failed nearly every goddamn assignment because I just can't).

I think of the global picture and just start programming and that has never failed me.

Others plan ahead and make technical designs and such but that doesn't work for me.

Just do what works for you!

Someone I respect always used to say "the more time you spend sharpening the knife the easier it cuts". Development is the same.

@SIgInTheHead Do you mean planning before programming?

If so, that doesn't work for me at all 😅

Indeed I did, I can do things either way.

Normally I jump in, then step back and plan, then code again.

Absolutely normal.

Curiously enough, the same applies to story authors. There's the "pantsers" who just sit down and write their first draft. They'll worry about details and consistency and other things in their upcoming revisions.
OTOH there's the "planners" who create an elaborate outline for their story, character sheets, etc and only start writing when they are happy with that high-level view.
And both write great novels.

You and I are the developer version of the latter. We don't like to jump in and refactor later, because more often than not we got lost, painted ourselves into a corner, etc.

Don't worry about productivity. We are just as good as the former type. We (and others) may get irritated because we type far less on our keyboards - but that means nothing. We reach the same goals in the same time, we just take a different path. And that's what matters.

I’m same, this hackathon culture has ruined so many things.

@SIgInTheHead yeah this seems to be a good strategy too - sometimes learning from mistakes is the most efficient way of spotting better solutions. I guess it all depends on what aspect of the architecture one is working on, but I have felt some days that it would have been better to dive in and reiterate later

@VaderNT that is a great analogy

@theunknownguy I’ve always struggled with hackathons. There seems to be two approches I’ve seen - those who are familiar with the tools who are there to refine their skills and those who are mostly there for the social aspect (been to too many hackathons in the beginning thinking it was a good way of learning new tools but spending 2 days learning how to setup an environment vs everyone else trying to actually do the challenge).

I think hackathons can be pretty useful, but only to those who are experienced with the existing toolsets and within a company, put aside time to create new tools.

@succyproggy hackathons are good for getting a solution, but some of those go way overboard asking for refined products

is normal, overplanning a oneshot project is too much effort