[Philomath]

I love a comment in the Reddit post where a user asks if he takes feature requests and proposes one (triple click on text to select it). The guy, shortly after, answers saying that it's a good idea, and that he just implemented it.

I don't love it because of the attitude of the developer (which is great too), I love that it reminds me how fast it is to solo develop something and how much more complicated it gets when a team grows.

(We are a small team of 15 devs in my company and it's already super complicated to be that efficient)

[elaus]

It only took him two hours after the feature request was posted until the change went live. I guess that kind of speed is only possible if you're a solo developer that takes full responsibility for his product and who is product owner, dev-op, UX expert and QA all in one person.

[sophistication]

Notably he was also answering other questions in the AMA, so it possibly only took him 2 minutes. It is not a difficult feature to implement anyhow, it probably went like this:

    vim tools/Text.js
    self.addEventListener('click', function (e) {
      if (e.detail === 3) {
        self.selectAll();
      }
    });
    :wq
    git add tools/Text.js
    git commit -m "Add triple click select all"
    git push origin master
    Done.

[IvanK_net]

Almost ... but I use Notepad++ instead of Vim. And I had to implement the search for the first and the last character in a line according to the layout. It took me about 10 minutes :)

[pwaivers]

This is super interesting :). Just curious, why don't you use a more advanced code editor than Notepad++?

[umvi]

I'm always amazed when people ship cool software with what I judge to be crappy, obsolete, or even downright dangerous processes/practices. Yet even though I (by my own judgement) use superior processes and practices (VSCode + Git + CI pipelines, etc.), I haven't shipped anything nearly as cool.

A few others that come to mind are KeePass/Dwarf Fortress (no formal VCS), and GRRM (uses WordStar 4.0 in DOS)

[softawre]

Maybe you spend too much time on processes, getting things right, and less time on actually shipping something useful?

[yakovdk]

I kind of put vscode in the same category as notepad++. Actually, as a text editor, I think N++ has some nice features that vscode doesn't (like macros, I think).

[gammateam]

He could have done this just as fast using GIT + CI. VSCode would have likely slowed him down with indexing, and he already knows where all his files are so there wouldn't be any gains from hopping around function declarations with the click of a mouse

Although you didn't pinpoint a single process that was inferior, knowing when to break processes is part of the experience.

[IvanK_net]

Thanks :) I already discussed it here: https://news.ycombinator.com/item?id=15924664

[kakarot]

Cool project. Playing around with it now and I love what I see. Must have been very fun learning about how to implement image filters and such along the way.

Any particular reason you choose Notepad++ over a full-featured IDE for a project of this scope?

[mcintyre1994]

Neat, I didn't know about detail on mouseclick events :)

[AltruisticGap]

The main view is a canvas. Regardless, my hunch is event delegation would be more performant.

[jancsika]

And because it's a webapp the user accesses the new feature by clicking "refresh."

Compare that to building binaries for all supported platforms, testing, publishing, dripping down into Debian & Ubuntu, someone on Ubuntu-Based-Distro-#1377 reporting a dependency problem, someone old Debian complaining that their compiler is choking on a gl library under armv7l, etc.

[Nadya]

Unless the user is using IE11. A perhaps not-so-modern but still a mainstream and typically supported browser. But if you're going to specify "old Debian" I think it would be fair to expect it to work on "old browsers" as well. But I think it would be silly to expect it to work in IE 5 anymore than some modern programs working in some old flavor of a Debian distro with outdated libraries.

At some point, like people do with dated web browsers, developers need to tell users they need to update as the developer won't be supporting such outdated software anymore.

[analogmemory]

In the same vein, someone says it's not working for them in WinXP IE 8

[Aeolun]

I’m fairly confident that I could have built more or less the same product that our team of 30 has built over the past 5 months in the same amount of time by myself.

If I’d had 1 more senior developer and a designer/front-end dev, I’m fairly certain it could be done by now.

But there’s so many people involved in the process that everything slows to a crawl.

I’m sure our clients love hearing that the product is developed by 30 people over 1.5 years though.

[dingaling]

Are you good at business requirements gathering? Environmental architecture? UX design? QA functional and regressional?

Fancy juggling AWS config and costs? Writing user manuals, help desk scripts?

On a scratch-itch OSS project you can ignore those. But when you plan to sell it, things scale quickly. Coding is just one arrow in quivver.

[Aeolun]

Most of those? There’s no point to me doing QA on my own product, and I hate writing any form of manual with a passion (things should be understandable without one).

But the point was mainly that the actual product is essentially a glorified crud application.

There is some value in having a larger team, but the time wasted is absolutely massive.

[paulryanrogers]

IME it's easy to look back and focus on doing the knowns. But starting from ignorance and alone is likely to take longer than a skilled team starting from scratch. Of course it must be the right size to explore and implement the solutions without too much overhead.

[saalweachter]

There's also a number of projects that it's super easy to do like 83% of.

A couple of ambitious college students could make a basic web crawler and search engine using 2018 technology and not even that many cloud resources and get like 80% of Google's quality. But that doesn't mean they're only another long weekend from being the next Google: closing the gap really does require millions of manhours and billions of dollars of compute.

(And their web crawler would be causing chaos and destruction across the web, but let he who has not accidentally deleted someone's will by crawling all the "delete this article" links cast the first stone.)

[bane]

I just saw a demo by a team of 30 that had worked on a super secret project for a client for the last 3 years. It was a web page that let you enter in SQL queries and select which database from some set of databases they've integrated to run it against...and then save the query with a name.

In my area, we've literally built something more or less like that a few times in the same time with one or two developers each time. In fact, I found out after the demo that much of the core logic came from a repo a guy on my team wrote in his spare time to plug a hole on a minor side project he was doing.

[tcbawo]

Owning your product (ie. reaping the rewards of your labor) is an enormous motivator. It takes a skillful manager/salesperson to keep people motivated as a company grows and they have less skin in the game.

[ekr]

Or a fat, annually growing paycheck.

[all2]

Money does motivate me to an extent. Ownership really lights my fire, though. Given the opportunity to really own a thing, to take responsibility for it, is something I've been looking for in employers and potential jobs.

[dkersten]

I follow the development of a header-only C++ library that I use and, besides a small community of users who help the author test and report bugs, its just one guy and the amount of features he's implemented in the past few months, due to him or members of the community needing the feature, is quite substantial. Its always wonderful to see substantial features or optimisations implemented shortly after seeing a discussion on it. The velocity of some of these projects is incredible.

Its not necessarily just "small teams move faster". It can be, but also it depends on the passion and energy of the individuals.

[adamnemecek]

What’s the library if I may ask?

[dkersten]

https://github.com/skypjack/entt

Its a great Entity-Component-System library, but better than the library itself is how active and approachable the author is.

[ggregoire]

You are also more efficient when you work on something you love.

[smnscu]

Can't a CI/CD pipeline + various processes be good enough to achieve a similar efficiency for under-100-engineers companies? Honest question - because I'm pretty sure I've heard some people claim similarly fast "idea to production" times.

[barrkel]

Usually, feature requests go through a product manager who can do analysis, integrate with road map, prioritize against other features, figure out if there's overlap with another feature (maybe one coming up soon) and so it shouldn't actually be implemented, etc.

There may be some communication between product and design to figure out how it should look and feel.

Then it'll go into a sprint most probably, but not the current sprint, because that would change the scope and affect estimates and possible delivery timelines. You'd only change the sprint scope if the team is running out of work to do or there's a major customer request or other panic.

There will be some measure of QA, ideally. Some people fly by the seat of their pants, and rely on fixing things in production if it breaks in production. This is using your customers as QA. Can work if you roll out gradually and are very responsive to any reports of regressions.

All in all, this is unlikely to happen in less than a couple of weeks. The processes are designed for predictable, consistent delivery and to minimize surprise. Shortening the chain will mean less integrated decision making and will increase the amount of surprise and inconsistency in the product and its delivery.

[sophistication]

The processes are also designed such that people do not feel overstepped and ignored. After all, most things in life are about social status, or more immediately about salary status and job position.

If someone secretly implements an awesome feature, others might be envious as it does not seem deserved if their idea did not receive the same level of scrutiny by the usual processes as other decisions did.

Theoretically, it probably won't cause much chaos at all if programmers are allowed to add small GUI tweaks and the product likely benefits from it.

The degree to which this would work probably depends a lot on the extent to which the programmers have reached Kegan level 5, so practically it probably won't work all that well.

http://i.imgur.com/K4AVFbW.png

[sidlls]

It's pretty rare for someone to secretly implement an awesome feature. Usually the way that works is as you hint at: someone who already has high social status in the organization gets a lot of leeway to do his own thing while everyone else is constrained to the usual process.

The envy isn't about the awesome feature: it's about the fact that this developer gets even more attention and positive notice from leadership by means that aren't available to other workers due to social status (rather than merit).

[tcmb]

To add to this good answer: in many cases you also don't want to overwhelm the users with frequent, unexpected changes, especially in 'enterprise' software.

This is not so much a problem when you add a new feature like this triple-click which doesn't change existing usage and workflows. But even here you want to add that to your documentation, inform your support staff about it etc.

For changes that affect the look & feel of the product, your users will curse you if you roll out multiple of those per week, even if everything is totally stable and free of bugs.

[markatkinson]

Not so sure. One developer understands his whole code base and environment quite well. So let's say an error occurs during build it's likely he will be able to check out the logs, navigate to that area of code and troubleshoot.

In a larger team the flow of info is DevOps/Developer spot error in CI/CD, find out which commit/Developer broke the build. Email/slack/ walk over to let them know and sit down for a friendly troubleshooting session.

Resolve the problem. Follow necessary processes to commit change. CI/CD hosted agent is busy building other projects because not enough budget for multiple hosted agents and all CI/CD is handled in the cloud. Time to go home!

Obviously that was a bit facetious but you get the picture.

[slivym]

Can you imagine running a company with a product where 100 people feel empowered to make small tweaks to the UI without going through a prioritization and design process?

[sidlls]

Sounds like a nightmare to me. Probably most of those developers secretly think they work with incompetents.

[jatsign]

Our team requires code review, and often times the comments are non-trivial. I think feature A could be implemented this way, a teammate thinks it should be done a different way. Neither way is wrong, but it requires either the team come to consensus (takes time) or the team lead makes a call (and potentially ticks someone off).

Additionally, beyond trivial projects, some changes may require changes to architecture, even small ones. A new feature may require a new index, a schema get updated, a new worker be setup to run in prod, etc.

And usually there are multiple PRs waiting to be added, which have to be deconflicted, and the lead dev still wants to code so everything takes longer than you'd think.

[test1235]

I reckon it's more of a question of bureaucracy than technology. If I were to do something like that on the project I work on, I'd need at least four other people involved, and a stack of meetings to get the feature approved for development.

[badpun]

Just a CI/CD run can easily take an hour or two. Add the code review back-and-forth (mostly waiting for reviewers, but also waiting for CI after every iteration) and a change that you could do solo within a two hours will take a couple days when working on a team. I've yet to see it go faster than that.

[bigbluedots]

Yes, but most of the time a new feature request will be in a backlog behind many other things, at least in most places I've worked

[jasonlotito]

> Can't a CI/CD pipeline

Those 100 engineers have to first agree on a CI/CD pipeline.

[tambourine_man]

I don't think I could work any other way without feeling miserable. The one person freelancer model is just so much fun. My only regret (and it's a big one) is that being around smart people is a great learning catalyst.

[christophilus]

Surely there's a way to have both? Meetups or co-working spaces, maybe?

[tambourine_man]

Yeah, I’m trying.

[christophilus]

I may be in the same boat as you eventually. I’d be interested in hearing your solution if you find one, and am happy to join a remote meetup if there is one.

[thisisit]

IMHO you got it backwards. It's less of a question on efficiency than priorities. I doubt that if the request was too complicated to implement or the feature was for a very specific task (look at opening raw images in this very thread) there will be such quick response.

Larger teams suffer from the fact that everyone has number of requests and prioritising one over other gets even more complicated. Even a simple request like this might have to go through a pipeline.

[sfoley]

Classic case of confusing correlation and causation. Large teams work on large projects. Large projects have large audiences which attract large numbers of requests. The smallest change in the world is going to get lost in all that noise.

[maxxxxx]

You can be that quick with a relatively new product but once you have a few years of legacy code and a large install base then every little chance can have unexpected side effects and is much slower.

It certainly helps to be a solo dev but that's not all.