Take Time to Develop Fast | Hacker News Reader

Take Time to Develop Fast

blog.tapin.tv

60 pointsddt24 comments

> You should have a strong opinion on every major area of software development

Strong implies stubborn, and stubborn implies inflexibility. The last thing I want when trying to debug a legacy system is a new hire complaining up the wall about XML bloat. It wasn't my decision, we are stuck with it, and let's move on and ship.

I think every developer should have some (shred of) experience in every area, and have knowledge of various options and the tradeoffs between them, but don't go around becoming that die-hard religious guy on the NoSQL/SQL debate (or any other for that matter).

I agree, and this reminds me of two other quotes.

"Strong opinions, weakly held" http://www.codinghorror.com/blog/2008/05/strong-opinions-wea... http://bobsutton.typepad.com/my_weblog/2006/07/strong_opinio...

"I aim to fight as if I am right, and listen as if I am wrong" http://blogs.hbr.org/sutton/2010/08/its_up_to_you_to_start_a...

"Strong opinions, weakly held" sounds right to me.

I couldn't care less how confidently somebody holds an opinion.

I think the word "strength" here should signify a battle-hardened opinion that has won out over others in a practical or theoretical sense. Strongly-supported...?

That's not to say that that it's wrong to be confident in the opinions you hold, but if you want to have strongly-supported opinions you can't protect them from being tested against other opinions. Let them win on their own merit...

This post deals more with setting up the best possible environment at the beginning of a project, rather than joining a team. You obviously have less say in that. This section's not about being sycophantic about a particular option, it's about knowing what works, what doesn't, and why. Starting any project with a lackadaisical approach to how you're going to execute can come back to bite you in the end.

At least from my point of view in writing the article, strong -> power to move; stubborn -> refusing to move.

I don't think anyone should be die-hard anything, because there's always a lot of grey area, and, as you said, you can rarely work in such an ideal environment. But having an idea of the tradeoffs you're making is extremely useful.

You certainly can feel superproductive working on greenfield projects and, once in a while, actually be superproductive.

I've found that the skills of a maintenance programmer are sufficient to punch my meal ticket. Early in my first W-2 job after grad school I took pride in my ability to pick up any tools and solve any problem with any system. Since then I've never been unemployed more than 2 days.

Since then I've fixed linux kernel bugs and built Silverlight applications with Visual Studio. (Ok, I have taken "Cold Fusion" off my resume.)

From time to time I have gotten into conflicts with management that it takes too long to do things -- but between learning new environments and understanding new systems, maintenance work is slow.

One critical skill is understanding a system enough to make surgical changes. Many people look at an old system and they want to tear it up completely and rebuild it -- often they think they can do this quickly, but often they understand at most 10% of the functionality of the real system. Other people, pressured by their boss, make a quick patch (that's not so quick) that ends up breaking other things. The work of understanding the code so you can make a small change takes a while -- yet, I think it saves time in the long term because it's better to spend 3X the time to get a 95% chance of success than to plan something half baked in X time that has a 25% chance of success and blow the schedule by repeating that mistake repeatedly.

Greenfield development is risky, making it harder to get a good a job doing it.

To take an example I spent much of the last six months building a beautiful system from scratch on my own dime.

Within two days of hearing about it, one of the largest companies on the internet made a concious decision to put me out of business. Tough luck, but any entrepreneur faces the risk they'll "build it" and nobody comes.

Another issue is that many "productive" greenfield projects are done by a junior programmer who is really proud of what they pass over to somebody like me to send into deployment.

Frequently these systems are full of bugs and come nowhere near meeting requirements -- hopefully you find out that the app malfunctions when somebody puts a single quote into an HTML field before it goes into production. Less than 50% of the effort has been done, but somewhere some smug opinionated programmer thinks he's the man.

All over the world, however, there are companies that have an existing system which is (i) critical to business goals and/or (ii) a source of revenue that they are not in complete control of. They need a professional programmer who's going to deal with the code in front of them and they'll pay for him. Yes there's a certain kind of stress that comes with this work, but that's the way it is.

Strong implies stubborn, and stubborn implies inflexibility.

NO!!!

Strong Opinions, Weakly Held[1][2] is what you want.

[1] http://bobsutton.typepad.com/my_weblog/2006/07/strong_opinio...

[2] http://www.codinghorror.com/blog/2008/05/strong-opinions-wea...

You reminded me of a developer complaining about the XML bloat in our product. He said "Do you know how much overhead XML adds to your page loads?". I responded "Yes, roughly 60ms on uncached page loads.". Later he proudly explained that he didn't know how to write html tables because he only uses CSS.

I've begun using a Trello board to keep track of the skills I want to pick-up and things I want to learn.

I have the lists "Heard about it", "Read about it", "Learning it", "Done with it". Today, for example, I added: "Learn about using Git bisect to trace bugs" to the Read about it board. Will probably play with it next weekend.

This is a new workflow for me, but so far it's working well.

How many skills are there already and can you show us some more examples please?

I know "me too" is bad form but since upvotes to pestaa's reply can't be seen this is the only way I can show encoderer that more people would be interested in more examples. (Blog it up if it would be too big for a reply.)

Learn and create my own Chef cookbooks vs just using Vagrant now.

Heard about using dsh as a, more or less, a reverse SSH proxy.

Figure out and use South django migrations.

Implement a bloom filter. Implementing a bayesian filter made it so much more understandable to me, I figure this would work the same.

There's a few other, more specific ones. But this is a fairly new workflow for me. I like the idea somebody mentioned about keeping a rough idea of how many hours you've spent on it.

Thanks for this. I may well augment what I already do with this. What I have which you don't do is on the "learning it" stage (although I don't categorise explicitly in this way) I have a square bracket with a number inside which I use to keep track of how many hours I'm working on each thing. You can see if you're spending too much time on something, or whether you've only done an hour (pretty useless, etc)

I fully agree with this article.

At my startup, Semantics3, we use Capistrano [1] for multi-machine deployments of our git repos. This has greatly helped our productivity as it just takes a couple of minutes to go from dev to production!

Through a single command (cap -f api deploy:start) our entire cluster get the latest git repo and all the services are (re)started - we use Upstart for daemonizing our processses and Monit for process monitoring. All of them seamlessly work together.

[1] https://github.com/capistrano/capistrano There is also nice gui frontend to it. You can do deployments through the web, with built in logging and user management! Its called Webistrano - https://github.com/peritor/webistrano/

> Developers love developing. (Perhaps recently computer science has gotten a boost in the number of those in it for the money, but for the most part those who I interact with on a professional level are in it for the fun.)

Ha. Just recently computer science got a boost in those in it for the money? I guess I started CS in 98, right during the boom times. Though our silly 18 year old selves thought we'd have it made, the 50% of our class who didn't actually enjoy it dropped off each year.

From my weak searching I found this, apparently majoring in CS is back on the rise:

http://cra.org/govaffairs/blog/2012/04/undergrad-computer-sc...

tapin.tv does a great job promoting what their startup actually does in their blog - both at the top of the page, and at the end of the article.

Thanks! I didn't write the article, but I'm on the team. We tried to make sure that people who care what we do can find it, but it doesn't dominate the page.

I think its good practice to spend a little bit of time each day or week trying to learn something new that will help you work[/play], a new vim command or feature, etc.

Absolutely. And then force yourself to adopt it. For instance, if you want to remap your control key to caps lock, physically remove your control key from the keyboard.

> “I like the BlackWidow Ultimate: it doesn’t have proper buckling springs, but it’s backlit and I like to code in dark rooms”

You... need to see your keyboard?

My passwords for important things (Google account, bank, etc) are 128+ pseudo-random characters, so it's a pain to get right without checking. Also I was surprised at how often I looked at my keyboard for typing numbers to orient once I started paying attention.

Ah, typing random characters can be a pain, for sure. That said, what was your calculus that leads to picking >600 bit keys? You'll likely be losing most of that to hash collisions.

10 hours? At my old company new hires would thrash around at least for 6 months.

And yet we made oomples and oomples of money.

Good SCM, easy testing APIs/harnesses and easy deployment are so wildly important, it infuriates me to work at one of the the biggest names in tech and waste HOURS a day on bullshit deployment issues or copy/pasting things in six different places before I can execute my tests or do manual verification.

For one project, deployment to production takes 3+ weeks, testing environments can take a week and is fraught with steps that take hours and literally can fail for any random reason and can only be mitigated by starting over.

And then I come home to my side projects that can be built with a single standard command that is more or less an industry standard. I can deploy it reliably every. single. time. I have a test framework that can be run from within my development environment or from the command line with the same tool as the build tool.

Reply on news.ycombinator.com