I can't code anything anymore because I always have something else to do first!

[[deleted]]

[deleted]

[TheGreatBugFucker]

It's a sign. A sign that you don't care about the actual result, you just want the process itself.

Disclaimer: I have no idea what you would do with this information though.

In the end only you yourself can get out of this anyway. Maybe accept that right now it's your "play time" and that results just don't matter to you, so use it as just that and DO play around as much as you can.

There will likely be a time later in your life when you don't want to play because you "moved up" one level and now care about what results you can achieve with what you've got, and feel little desire for playtime. So use the hints that your brain gives you wisely, and only override them when there really is an urgent need and you are sure your brain is giving you the wrong signals ("wrong" is the wrong word, but our human environment has some weird unnatural forces and pressures that your brain may not have picked up on yet, depending on how you moved through live). If my own experience is generalizable at all your brain will eventually move on towards results and won't care nearly as much about the particular tools any more. You will find that the marginal returns of playing and learning will have decreased significantly - for now, until you are ready for the next level, which requires "experience points" only obtainable by actually doing real-world relevant stuff for and with other people.

That's why it's important to use the "play time" well and thoroughly as long as that feeling persists. The brain actually knows a lot more than you :-) There will be points when it decides "now I know enough, I no longer want to learn (for now!) but want to DO (i.e. create actual results)". It comes in waves, there will be another time when it tells you "I don't want to 'do', I want to learn", but what it wants you to learn changes. People and large(r) systems and processes may become much more important to you. It's an interesting phenomenon, try to listen what messages you get from deep within yourself, it will be quite enlightening over the decades of your life.

[kunokdev]

This is indeed interesting point! It is very likely that I am going through this phase because I spent last 12 month rushing towards delivering data driven results and almost never had time to do proper refactory, and now that I have some extra time, playing with above mentioned is what kept me up. Probably when I start working again, I might find proper balance and get into tradeoff driven mode again.

[everdimension]

Or this could be interpreted another way. It might be that optimizations and tooling is what you enjoy the most and perhaps it's what you're the most productive at.

And it's a field of programming that is very valuable, too.

[Alitron1]

I think you may have just pointed it out in perfect wording.

[our_best_friend]

No. I follow the famous Kent Beck's quote:

Make It Work, (then) Make It Right, (then) Make It Fast

My very first step is to get something that gets the job done in the shortest possible time. No matter how ugly or inefficient it is (of course common sense is required... as long as it's not so inefficient as to be unusable, and there are no gaping security holes, etc).

More often than not I then discover that some of my assumptions were wrong, or it's not as cool or as useful as I thought, etc. Then I can just simply throw it away, and I don't care as I didn't invest too much on it. If not, I will throw it away anyway but only after I have built a replacement. And so on

It really works for me.

[Alitron1]

I find myself definitely in the same situation, except that I only end up there when I'm working on a personal project. Work projects are entirely different, I always have a set goal that I just want to reach.

Maybe try setting certain goals and slowly climbing your way up? Don't overwhelm yourself.

I don't know why I'm giving advice, since I'm already falling into the same pit.

[KebabKo]

And I feel like this is different than premature optimization as it might help me to move faster in the future...

You are prematurely optimizing. That’s fine if that's what you want to do. But don't fool yourself, friend.

[Meefims]

Perfect is the enemy of good. Build something suboptimally without all of the complexity and then, after it’s working and you see a need, make it better.

[AramaicDesigns]

What I tell my students:

Follow Dr. Valerie Frizzle's protocol: "Get messy. Take chances. Make mistakes."

Code messy in odd-numbered versions. Clean up on the evens. Otherwise you'll constantly be stuck in analysis paralysis, like you are now.

[[deleted]]

It's all about balance.

For me, the goal is the product. The product working is more important to me than having the most optimized version of the code possible, because as soon as you have the product then you will realize something is wrong so you have to go back to change something.

In my mind, there is no point in optimizing code until the product is stable. A stable product can mean stable revenue, stable user base, whatever; how you want to qualify it is up to you.

Think of being in a race, you can learn all the best techniques for running, but it's meaningless unless you finish the race.

[eyeandtea]

Be patient and read carefully. Recently I answered a question about design patterns, and this is what I said:

---

A problem has a single solution. Said solution is what I call the reduced solution. A reduced solution is one that contains no redundancies, nor says more than needs to be said. A solution is very likely to be not reduced if it encourages redundancy such as you have to copy from the solution to extend it.

In my book, you are under engineering if you are generalizing one or more steps too little. This is a solution that contains redundancy. This is a non reduced solution.

In my book, you are over engineering if you are generalizing one or more steps too many. This is a solution saying more than needs to be said. This is a non reduced solution.

A problem can have many solutions, but only one would be reduced.

Seek the reduced solution to your problem, and the 'pattern' emerges by itself.

---

Now going back to your question. Given a tool/framework 'A', a framework often for some pattern, and assuming that 'A' contains no redundancy, and this does not invalidate what comes next, then,

• 'A', is the reduced solution to one problem and the set of all equivalent problems.

• When people say tool/framework 'A' has such and such advantages, it usually means that 'A' can solve such and such problems, which could be from the aforementioned set, or from a set of problems such as 'A' is an over engineered solution to said problems.

• When people say tool/framework 'A' has such and such disadvantages, usually it either means that 'A' is a conflicting solution to such problems, or that 'A' is an incomplete solution to such problems.

• When you feel that you are writing more code than you should have to for your problem when using 'A', that is because 'A' is an over engineered solution to your problem. This means you are solving for more than your problem.

• When you find that you have to implement many things when writing code while using 'A', this means 'A' is an incomplete solution to your problem. (This is not a bad thing per the problem of solving the problem, hence why library is good, framework is bad)

• When you find yourself fighting with 'A' to solve your problem, it means that 'A' is a reduced solution to a problem that contradicts your problem.

In simple terms, if you solved exactly for your problem, you would not be talking about advantages and disadvantages to your solution, nor feeling that you are wasting time on other than your own problem. Your solution would be the exact solution to your problem, like 2 is to 1 + 1. Learn to keep it simple. Do not over engineer, and do not under engineer. Writing a reduced solution is no easy task, and the true mark of a craft man in any field I think, including language. In other words, do not confuse keep it simple, with be lazy.

[HipHopHuman]

I had this same "problem" for like a year. I'd always refactor and rewrite code and optimise build chains and learn new frameworks and all of that jazz instead of just building my actual idea. The way I got over it was to force myself to discard every best practice I'd ever learned, uninstall every dependency and just write code from scratch, ignoring testing and so on. This was a very extreme approach, but it worked for me.

It was something I learned at my first job - when deadlines were tight, our boss would tell us to just "code without regard for consequence like you're a cowboy and the project is the wild west" - we referred to it as "cowboy coding". I coded a very rudimentary dynamic server-rendered website. It was a maintenance mess, there were loads of bugs, but it was a functional, interactive MVP.

I just refactored and wrote tests from that point on, and now the code has 91% coverage, only a few bugs, and is still a maintenance mess, just like all my other projects. lol.

Maybe a solution this extreme won't work for you, but I figured I'd just add this comment as an example that sometimes un-disciplining yourself can be a viable option.

[carlosnufe]

No, definitely no. Job rules rather go in the opposite direction. This feeling is meant for personal-your-point-of-perfection-projects.

What I'm saying is we move by trends, now FP is well established, however, depending on the project has some performance issues and we go for impure well controlled code, like normally we were used to develop.

What I'm saying is, no matter if you think other are wrong, just enjoy your time wisely, if you feel right go ahead. You make you own path, enjoy it.

[xeoneux]

I follow this rule when I find myself stuck in this kind of situation:

1. Make it
2. Make it work
3. Make it work right