hackula1

More likely a strong tsk tsk in a passing speech.

Awesome. Excel, PDF, and SQL Server are the 3 most obvious proprietary integrations that have an enormous demand in javascript for commercial application devs. There are partial solutions for each, but anyone who has worked with them knows that they are miles away from the .Net and Java equivalents. Most of the current solutions are clunky, have onerous dependencies, or simply do not implement the common features that most people need. Keep up the good work, and I hope this encourages similar projects! These types of things are far from sexy in most of the web world, but turn heads in the B2B space.

> I wish people could make up their minds on what DVCS we should all be using and stick with it for 20 or 30 years

I know this is a bit meta, but this seems to go against the entire spirit of git.

Both awesome libraries, but I think including lodash and jquery in the list of small modules is a bit of a joke. Both are big old fashioned utility belts.

This

https://github.com/lodash/lodash/blob/master/lodash.js

is hardly the ~200 LOC module being described.

> The belief is it is easier to train a computer scientist to be an engineer than the other way around.

...and yet it still seems to take a lifetime of effort, discipline, and study.

As some one who rights stats libraries, I can see it now.

"Bug: code does not work with an input of 1"

"1 is of approaching-zero-significance when you consider all of the other test cases we are meeting. 1 is not the responsibility of this lib. Feel free to fork. ======= issue closed."

I try to put these in my issue tracker instead of the code. Same thing though. Sometimes my issues look like the rambling ravings of a madman talking to himself. https://github.com/morganherlocker/turf/issues/41

> Accumulation of technical debt is bad.

Is it always? In dollar amounts, I really do not know that it always is. "Don't let the perfect be the enemy of the good" and all. As a developer, I am always going to be the one push for better tests, more efficient systems, etc. but pg's post a month or two ago about scaling without automation (very rough paraphrasing) points to the fact that this does not always hold.

> The latest trendy programming language won't make your hard problem all that much easier to solve.

Maybe not the latest, but I would think that it was way easier to develop a desktop app in C++ than Fortran, develop a website in PHP than C++, develop a web app in Ruby than PHP, etc. Tech definitely improves over time. Jumping on every third bandwagon seems to be worthwhile.

> A complex system can't be properly integrated and tested in two weeks (as recent news reports have shown).

> The CEO setting an arbitrary deadline doesn't magically alter the laws of physics.

These are not engineering problems, but political/administration problems that have been around forever and in every endeavor. I am certain that stone masons building cathedrals dealt with the same sorts of incompetent management, despite a dedication to craftsmanship and engineering.

I find that in this situation, my response is always the same: "Just do it.. be right back"

Which kind of web apps? Not everyone writes todo apps these days. One of our devs retired last week. There are probably less than 20 devs in the world with his skill set (very specialized geospatial analytics). Even todo apps can require extremely talented developers to work at scale.

I am in a position where I could work remotely, and I would like to, but for one reason: career advancement. I am pretty early on in my career (about 5 years in), and I have basically two competing routes ahead of me A) be a highly technical dev who will be a high value "mercenary" type or B) move into a technical lead/CTO type role. I always thought that I wanted to do be A, but as I have gotten into product design, building up a team, mentoring, negotiating deals, etc. I have found that I really enjoy B. Being a lone wolf type dev is almost ideal in a remote setting (all of my clients are already off site anyway). Being a manager, technical lead, or anyone core to a business team, however, seems a lot more difficult to pull off.

I used to love the idea of working as that story book hacker who can spin out code from a laptop in an RV traveling where ever the wind took me. I work with a guy who literally owns a laptop, a suitcase, and the clothes and toiletries to fill it. Every morning I talk to him he could be in German, Brazil, Japan, or where ever the hell he feels like going. That is awesome, and I highly respect anyone with the spine to live that way, but...

At the same time, I want to be in the fight, shaping people instead of just machines. I want to be able to shake the hands of the people I work with, and look my competitors in the eye. For now anyway, I am sticking to the office and reaping the career rewards of being a central figure to my team.

TLDR: work can be done from anywhere; leadership.. not as clear.

Unfortunately "programmer" has come to be synonomous with "fancy typist" by the people who pay the bills. "Engineer", "architect", and "developer" all imply someone who codes with a focus on X, whether it be low level reliability, high level design for scalability, or general competence and requirements gathering skills.

Waterfall software design would also probably work if it was not for changing requirements, limited budgets, optimistic estimate push, etc.

Granted, most engineers are not exactly employing quantum physics to parking lot design. Most people, in general, work on gluing together pre-built parts that they do not understand all of the fundamentals of.

You are correct, but I would point out that this does not detract from the argument considering the time scale. Software engineering could be 150 years old, and still not have the close to the history of traditional engineering.

While this would not work for many people... I log most stuff to a database. I have an admin panel where admin people can perform simple extracts. The extracts can then be crunched by analysts in any way they want. We don't have millions of users, as we are B2B, but it lets the sales guys load the data into an excel template that does what they want. Then they can focus on what people are using and what they should pitch towards. This would probably be a terrible solution for high user apps, but it has worked great for high value low user stuff that I usually deal with.

As a long time buyer, I have had zero problems. Anecdotal evidence, obviously.

Probably not, but no one could have predicted this of Sony when they started out making tape recorders. The initial product does not seem to matter much on this time scale compared to capital and investment prowess. Twitter looks like it is making a pretty strong start on one of those, but we will see what the future holds. http://en.wikipedia.org/wiki/Sony#History

Does testing have much to do with it? What's the angle I am missing?

Only if you told them why, in a "right to work" state.

Agree. I am sure Yahoo has some cruft at the lower levels, but I would imagine that the real problems are in middle management, where many of the worst are the most adept at playing the game with the higher ups after years of practice. I really do not know of any great ways of solving this, but I have seen the problem many times in companies of similar size.

Does it really matter to them? (serious question)

I agree with everything except that a PM can be extremely valuable on a small team. Developers are much more valuable designing and coding than in endless meetings and planning sessions. That said, IME PMs should be at the same level in the hierarchy as the devs. PMs manage projects, not people.

We have an unofficial line in our contracts with both employees and customers that essentially just says "I will try not to be an asshole". It does not always work, but I like having an expectation set up front that everyone is going to put in the minimum effort towards being reasonable.

I tend to have strict unit testing with near 100% coverage for libraries. For application code, I use primarily sloppy integration tests. This seems to be the right balance for me anyway. That being said, I try to extract as much app code into libraries as possible.

I did the same a couple years ago. Development speed has sped up drastically.

Convenience mostly.

I genuinely wonder how it is possible for paypal to have such terrible design for so long? Everyone knows its an issue, and it seems like a couple 100k in design work would clear up the issue for the next 4-5 years.

I feel like this comment might sum up the difference between high traction B2C and slow and steady B2B. At no point do you mention the closing or cashing the check. Your approach is perfectly valid for most B2C stuff, but as a B2B guy, this looks completely foreign. Definitely a learning experience for me at least. As a B2B, this approach would IMHO fall on its face miserably, but I can totally see how this would be effective when more users == more value and sales-guy-on-a-phone is not scalable. That said, for B2B people, I would be highly skeptical that this approach would work. When your market is small, you had better have closers on the line to ring the bell.

If we had a list of all the bitcoin wallet values (even estimated) we could use this http://en.wikipedia.org/wiki/Jenks_natural_breaks_optimizati...