Hacker News new | comments | ask | show | jobs | submit login

That shipping stable software that works and meets requirements is what people really want. In other words, what the non-tech business people want, or your customers want, is software that fixes their problems, makes their lives easier or makes them more money.

It's easy for us programmers to become fixated on using a newer JS framework, a slightly tighter Java loop or the latest cool language. Took me a few years to realise that even though I care a lot about those things, other people do not. They are interested in the outcomes, not how it got built.

I'm running my own business and building things for myself these days. I use vannilla JS on the front-end and Java 8 on the back. Since I gave up chasing the new cool tech I have built a bunch of stable systems that have been great, well received, products.

If you become someone who has a history of shipping things that work, you will do a lot better than someone who knows how to write hello world in every JS framework.

This. Make your _business_ case, not a technical case. This applies to software engineering, security engineering, etc.

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.

Here's my problem.

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?

Personally written organization helps me. I like to use Trello to organize my thoughts. When you get an idea, write a quick note to get it out of your head so you can stop thinking about it. It's written down, you now have the freedom to let go and attend to it later. Schedule specific time to look at that list and put it on your Calendar so you don't forget. "I don't need to think about that right now, I made time on Sunday afternoon to prioritize and pick out which ideas are worth it." or "I will only check my ideas for things to refactor when I have a lull in my schedule, but I'm busy right now."

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.

Your completely right, and it's something only someone with ADHD can understand. Depending on how bad your ADHD is, mental partitioning will be incredibly difficult thing to do and that has everything do with lack of attention/focus regulation.

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.

Your "problem" sounds different the one I currently deal with.

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.

Also, "freeze" your "features" at versioned levels for each project.

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

Otherwise, you will never finish a project.

eg. "Sprints" in Agile

Like the work you deliver to your boss or client, there is a Final Product.

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

ADHD sucks. I have it, too, and I somewhat solved this problem by moving into R&D, where they pay you for ideas directly. But these fields are rare (quant finance is one of them).

I also have ADHD which has reached debilitating levels at times. Noise cancelling headphones, removal of computer games, and being disciplined has helped. In all seriousness though, it's a more complex condition than most people realize and seeing a specialist is never a bad idea.

This! and know why you are building what you are building.

I printed this XKCD specifically to remind myself that some things aren't worth automating!


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

Or the fact that the task is so mundane/boring/annoying/irritating (pick an applicable adjective) that it's worth it to you to spend a day automating it so you never have to do it again.

Great point - the benefits of automation can't always be reduced to time saved per operation. I wrote a blog post [1] about this in response to that xkcd.

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

The problem with that is if you make a mistake the first time, then redo it by hand, you have used up 20 minutes. Made a second mistake, and you are even with automating it.

also keep in mind: https://xkcd.com/1319/

I agree completely with this post but want to provide some additional insight that I've gained:

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.

This is why I always ask what is the business value of doing cool thing X on a project.

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".

Along those lines I'm always surprised at how many SUCCESSFUL tech companies even today are built with PHP. Tech stack is often not the driver of success or failure in a company.

Besides, PHP is a mature and very well working technology. Not shiny, but otherwise very good.

There's a balance to be struck there, though, and pejoratively referring to the seeking out of ways to improve as "CV driven programming" probably isn't the healthiest attitude out there. If you're not doing new things, you run a very great risk of sitting in a weak local maximum. Don't fix what isn't broken--but you need to be stretching out, too. Not doing so induces a sense of stagnation to a team and can chase off developers with ambition (which you can and should harness) and a sense of quality.

I agree there is a balance to be met.

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.

> What I am against is just adopting tech that doesn't improve anything

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

Pilot projects, technology analysis, market research, reports from external consulting companies, architecture assessments, university projects,....

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.

There are plenty of cases where new frameworks come out that allow you to move forward much more rapidly as a dev team. They allow better testing, better code organization, etc.

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.

On JavaScript world, old techniques and architecture lessons are being rediscovered every day. There is hardly any invention going on besides JIT compilation improvements for dynamic languages.

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.

I strongly agree.

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]

Also there are differences in further employment perspectives.

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.

That is true and can be a problem when recruiters just keyword match technologies from your CV.

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 find it funny that you felt the need to distance yourself from Java.

Are you using a java framework on the backend? Something like Spring maybe? I'm just curious, I've been thinking about using Java for the backend of my own projects.

I have used Spring before and I like it quite a bit. I have tended to use vanilla Servlets for most of my projects recently and use libraries like Gson, Apache Commons, PdfBox etc etc where appropriate.

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.

I appreciate the reply, thanks!

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

I wouldn't suggest this sort of self-damage; I've been there and I've made the mistakes. Servlets, as written, are lousy abstractions for HTTP. Worse, where the abstraction breaks to expose HTTP to you, it doesn't really do much in the way of enabling you to do anything you couldn't before.

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.)

I have to agree with parent heavily and I used to be a long time Spring advocate since version 1.0.

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.

> 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.

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 think you may have misunderstood me a little.

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.

> "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."


“A reminder that the goal of a given computer program is first of all to meet some business requirement may come across as a platitude. In practice, the excitement of technological challenges often slowly causes attention to drift from the end to the means…”

—Stephane Faroult, “The Art of SQL”

What application server do you use for the backend? Tomcat?

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact