The above comment does not absolve you from doing cool things, it's just that the cool things should align with business interests. No yak shaving. Sometimes writing a one-off script will take 30 minutes, and doing it by hand will take 10. Do it by hand.

I'm not particularly prolific, so the number of ideas I have far outweighs my execution so far. This is mostly due to ADHD and other issues which I'm working on fixing, and while contextually relevant is not my point.

This lack of prolific-ness means that I have a literal tower (it's rather intimidating) of wanting to build cute but objectively not so useful routines simply for the sake of building them.

I realize this is essentially the foundation of creativity, but I have a hard time justifying doing these things as I take a very long time to execute anything.

So, the ideas file themselves away - and surface when I'm trying to design actual things I'd like to build. And I get horribly distracted with doing X or Y a certain way, or I get carried away with how I can build Z out like this or that idea I had two years ago...

My problem is focus, I think, and mental partitioning, which I'm not good at. Does anyone have any suggestions for how I can do that?

Also on the tower of ideas-- it's not a to-do list, you don't have to commit to every idea that flies through your head. Your ideas are a great resource for you to reach for any time you need it. A lake of ideas you only need to go fishing in when you happen to want to.

You will have to find a way to develop the capabilities of your brain(working memory, long term memory, task execution and completion, focus and accuracy). You will have to do something that you have been evolved to do which is to have a creative outlet (Dancing, Music, Art) to develop those abilities. There has to be a task where you have infinite focus/hyperfocus, that builds a higher ability. In a sense you don't have to do something that is hard, but something that comes natural and something that grows.

The sequence of steps and motions that are required for dance, movement of muscles to precisely line up with the notes of a song, to reproduce the form of a drawing/painting all require some sort of mental partitioning. These things are all interrelated. I personally have only scratched the surface, because things become infinitely complex I have to decide what is the most important develop. If your lucky enough to be creative and logical these abilities will bleed into each other.

My current solution is to have a backlog and spending time to prioritize them. I'd focus on my top priority, and continue writing down new ideas as they come into my mind. When I finish with the top priority, I re-evaluate to find out where the recent ideas fit in. I'd also look into reading about the agile methodology.

If you're like me, ideas come in very frequently. Embrace your creativity and ambitions by logging them. But try and shift your mindset to thinking about what is actually necessary for the final product.

If you want to add or alter something, that would be a new project.

Otherwise, you will never finish a project.

And yes, Agile is the best, because it's of the mindset that the Product is iterative!

https://xkcd.com/1205/

On the other hand, sometimes you're automating for reasons other than time savings. Maybe reproducibility or auditability.

[1] https://andrewstahlman.com/posts/IsItWorthTheTime.html

Learn to enjoy your work as that's the only way you'll make it long term. If that means spending a little extra time to write an efficient algorithm or structure your code efficiently v.s. just "getting it done", then do so for your mental health, not for the company.

You see, we're craftsman at the end of the day. We all want to feel like we are contributing quality work, and often that conflicts with the business's priorities. Take pride in your work and you will find it easier to show up at the desk each day.

Using your words if "using a newer JS framework, a slightly tighter Java loop or the latest cool language." doesn't improve the business value of what the customer is getting out of the product, it gets a very big NO.

I became very much against "cv building driven programming".

For greenfield applications, chose whatever the customer ask for on their Request For Proposals, or suggest modern solutions if they leave it open to proposal reply.

On existing solutions, deployed for several years on the field, actually measure what it brings in regarding business value. Either in terms of reducing project costs thus improving profit, or improving customer UI/UX thus improving the value the customers get out of the product, specially if it helps them to improve their profits.

What I am against is just adopting tech that doesn't improve anything, sometimes even causes products to be abandoned or removed from the market, just for the benefit of a few devs improving their CVs.

I have taken part in a couple of projects where it actually happened. Architects were busy chasing the new shinny instead of delivering what customers actually cared about. In the end the product was canned.

How do you know what improves what if you don't use it in anger?

There are many ways to research new tech without touching the current product development.

Sometimes it is better to be the turtle than the rabbit.

Especially in the Javascript world, it's such a new field that new techniques are being invented regularly. I've seen old backbone applications that are essentially frozen in time feature wise, because the code is so cumbersome and coupled together (by the framework's design) that it becomes impossible to add new features without having to refactor/rewrite the entire thing.

I agree, if you have have a finished product that won't be getting many new features at all, then leave it alone. But if it is an ever evolving product with new use-cases and features being dreamed up regularly, that application should probably be re-written many times over.

As for CV driven programming, here is a real case from a long gone project.

Dumping a fully working and battle tested Perl scripts for application installation in several flavours of UNIX, for Groovy based ones built on top of Grails.

It really improved the business value of those customers having to deploy a JVM, executing scripts slower than before and what was a simple set of CLI commands turned into starting Grails and navigate via web pages uploading files.

However, there are special cases where you are exposed to a new technology which enables new outcomes.

I was fortunate enough to blunder into using the Web in '92 and Java in early '95 and they were tools where the "how" did matter quite a lot...

[NB I haven't touched Java in a dozen years or so]

I mean if you have a problem to solve and you have a choice to use some old tech that you already know, but it is going out fashion, and some new one, then the choice of the newer one improves your employability in the future. For example, I guess in 2000 there was not that much people with 5 years of experience of using Java in production, but those who had it, had to have pretty good chances to easily find decent job.

Of course there is a risk to bet on wrong technology, but at least you keep learning instead of just using ageing tools and becoming more and more disconnected from the current state of the art. It can be as scary as this https://news.ycombinator.com/item?id=11886753, a story of a guy who successfully solved business problems and delivered products with jQuery for a long time and then eventually found that he was out of demand because businesses started looking for people with experience of using React and he didn't have it.

When I've recruited I've always tried to assess the candidate on ability to get things done rather than knowing a specific framework. I'd look at how deep their knowledge goes and see if they can ship stuff - if they've been using jQuery but I need React then I'm not too fussed if they've shipped quality products using jQuery and have taken the time to learn pretty deeply how it works, the keenness to learn and ability to build things should easily translate to React and I'd rather have this person that someone who has skimmed the top of React for a few Hello Worlds.

I would hope and prey that interviewers would take a similar approach, if they are just ticking off keywords from your CV then it's a pain.

I think if anyone wants to go down the route of using Spring, Play or similar then you MUST spend the time learning it in pretty deep detail. I've seen so many people with "Spring experience" on their CV who can make a webpage appear using the tech but as soon as something goes wrong or they are asked to do something a little different they are screwed as they don't know the framework well enough.

I only use vanilla Servlets and my own stuff because I have been building up my own libraries and ways of doing things over time and I've been burnt enough times with old-school frameworks (like JSF and Seam) that just add so much unnecessary work and ball-ache.

I like to write the fewest lines of code possible and also use the fewest dependencies possible. I find that plain ol' Servlets gives me that for most of the stuff I do.

Perhaps I will try to use vanilla servlets for one of my personal projects. I'll have to start reading the docs!

If you want to use the JVM, one: use Kotlin over Java, it is a strict superset and a better development experience across the board. Two: evaluate something like Dropwizard (or even Spring Boot) well before you go near servlets. JAX-RS is not perfect, but it's a lot better than whatever you will home-roll. (Again, been there.)

The thing you will find using Java for a long time at any company is you eventually end up with your own framework / stack.... Yeah sure there is some underlying DI or Web framework but a majority of it becomes your framework and workarounds/plugins/extensions for whatever DI/Framework you choose.

I used to to think this was a terrible thing but these days I think using less dependencies, autoconfigure magic, and even using older technologies such as the Servlet API are just easier to maintain, understand, debug, stable and surprisingly easier to train new folks on.

This doesn't match my experience at all. Only really ossified organizations get to this state, even in Java-land. The amount of abstraction I have needed to put on top of Dropwizard in order to do literally everything I've ever needed, from websockets to web pages to file service. The underlying Jersey and HK2 system is simple, well-documented, and straightforward when I've needed to extend it, but these extensions are restricted in scope and easily testable to boot.

I see no benefit, in 2017, to using servlets directly. It's certainly not going to be easier to teach a new hire through look-at-the-code or look-at-our-minimal-doc instead of pointing them at the existing documentation and examples of best-in-breed tooling.

I'm not saying go use the Servlet API directly all the time but you damn well should know it since almost all the others build on top of it (including most of Jersey).

Particularly Servlet Filters. It seems like every framework has their own take on onion processing a request but servlet filters are actually easier to write then say some Spring framework "Advise".

As for Dropwizard... You do know its built on top of all the new JEE stuff like JAX-RS. I am willing to wager it will die and be replaced with something else... but those underlying javax specification stuff (like JAX-RS, servlet api, etc) are still going to be around.

You should know those underlying standard APIs.

The funny thing about you mentioning Dropwizard is it basically started as someones else stack built by mixing standard libraries.... something companies do all the time.

> I see no benefit, in 2017, to using servlets directly. It's certainly not going to be easier to teach a new hire through look-at-the-code or look-at-our-minimal-doc instead of pointing them at the existing documentation and examples of best-in-breed tooling.

Until shit breaks, or doesn't fit your exact requirements or the project dies, etc, etc, etc and believe me it does happen in which case you will need to know the lower level stuff. But yeah don't reinvent the wheel.

This.

—Stephane Faroult, “The Art of SQL”