akeefer

42 ms·

301.
by akeefer 18y ago
That's one of the things that agile development should ideally give you (in practice, of course, it's never as easy as it sounds). You make short-term (i.e. per-iteration, often 1-2 weeks) commitments to get things done, and base the amoun
302.
by akeefer 18y ago
That's also generally the reasoning behind mocks, dependency injection, etc. used by OO unit testing. If something is supposed to, say, update something in the database, you abstract out an interface to the database and mock it out in your
303.
by akeefer 18y ago
I agree that he's got a point, I just get annoyed when people feel the need to make their point in a way that questions the intelligence of other people. It's unnecessary and counter-productive. There are ways to say "one big advantage of
304.
by akeefer 18y ago
I'd say that it's true that the closer you get to pure functional programming (no state or side effects), the more unit testable your code becomes. I'd have to take issue, however, with the author's implication that Java programmers who uni
305.
by akeefer 18y ago
Having spent the last 7 years working on enterprise systems for insurance companies (at a vendor, not internal IT), I can point out a few less sinister reasons. Sure, design by committee never helps anything, but there are just some fundam
306.
by akeefer 18y ago
Most of the Java "enterprise" ecosystem is the result of people trying to make simple problems more interesting by framework-ifying them to the point that they become hard. Not coincidentally, most of the Java ecosystem is also used by/bui
307.
by akeefer 18y ago
Awesome, awesome movie. Not for the faint of heart, though. Let's hope that Will Smith and Steven Spielberg don't actually go ahead with remaking it ( http://www.imdb.com/news/ni0615340/ ). What a travesty that would be.
308.
by akeefer 18y ago
In my experience, programmers think they know when they're being productive, but they're often wrong: for example, coding for 5 hours straight without realizing the time has passed might feel productive, but if you've been doing the wrong
309.
by akeefer 18y ago
Following rules slavishly is a pretty easy target; of course you want to do X because you think it's the right idea, not just because someone else told you to do it. But at the same time, often the only way to develop the intuition and expe
310.
by akeefer 18y ago
As someone who's conducted dozens of interviews over the last few years, I can tell you that there's no way to infer from someone's age or resume if they can code or not. Plenty of people with stellar resumes and 20 years' experience come
311.
by akeefer 18y ago
I know everything is moving to SaaS for very good reasons (both for the developers and for the customers), but one thing the old packaged software business had going for it was that costs were totally decoupled from pricing: your largest c
312.
by akeefer 18y ago
I'd say that it's also important once the team gets beyond a certain size; codebase and team size tend to scale together, of course, but not always. The value of tests in catching regressions in code you didn't write, didn't realize was th
313.
by akeefer 18y ago
We don't really pack people in or use laptops, we have clusters of 4 or 6 desks that form larger rectangles and which are then stacked back-to-back, so you can easily talk with the people next to/across from you in the desk cluster or you c
314.
by akeefer 18y ago
As per my other comment, I've worked in an open plan for 6 1/2 years and I'd say our development team is pretty highly productive. I haven't seen any resulting hostility or stress, it certainly doesn't feel like an assembly line, and we ge
315.
by akeefer 18y ago
I've worked in an open-plan office for the last 6 1/2 years, and I'd never go back to cubes, or even to private offices. The level of collaboration and knowledge-sharing is much, much higher, and while the level of distraction and ambient
316.
by akeefer 18y ago
Writing a Java bytecode emitter for my company's language (currently called GScript, hopefully open-sourced under a different name some time in the not-too-distant future). It's currently executed off the parsed AST.
317.
by akeefer 18y ago
Indeed . . . as someone who works with an in-house language, I can affirm that the ratio of time we've spent on the initial parse/compile steps to the time spent on things like error reporting and optimization is probably approaching 1:100
318.
by akeefer 18y ago
Both JRuby and Jython compile dynamic languages into the JVM; the instruction set of the VM makes it fairly difficult to deal with dynamic types and to deal with reloading methods on the fly (I believe that in Java the only real way to unlo
319.
by akeefer 18y ago
It's a solidly thorough list, but the upshot should really be "designing a general-purpose language is hard." Designing a special-purpose language or a DSL is easier, but in my experience a lot of seeming DSLs end up slowly accreting more a
320.
by akeefer 18y ago
We write a lot of what we call "smoke tests," which are essentially integration testing in most people's parlance. It's a long story, but we have a custom web framework that's widget-based, and one thing that allows us to do is to write UI
321.
by akeefer 18y ago
While getting on the same page is important, intellectual blind spots are a huge problem for most organizations. People who think too similarly tend to miss the same sorts of things, and it's absolutely crucial to the success of any seriou
322.
by akeefer 18y ago
I have to echo these comments, given that my current company was founded in late 2001. The horrific job market for engineers in the valley over the next couple of years meant that we could assemble a first-rate team much more easily than w
323.
by akeefer 18y ago
Generally true, though one component's "public API" is another (higher-level) component's "implementation details." I.e. just because a class has public methods, it might really just be an implementation helper for some other class, and no
324.
by akeefer 18y ago
I'm not sure I'd say "New Delicious was rewritten in Erlang" is an accurate title here. More like "certain subsystems of Delicious were rewritten in Erlang." As far as I know no one (or at least hardly anyone) is actually writing web-appl
325.
by akeefer 18y ago
The author definitely makes a mistake in equating slow programs with poorly-written programs. Yes, it's true that people who write horrible code often also write horribly non-performant code, and that rushing a product to market without pe
326.
by akeefer 18y ago
I agree with the programming/computer science distinction; in my experience the skillsets are fairly disjoint, and having a CS degree (or knowing what school it was from) bears very little correlation to someone's ability to code. Honestly
327.
by akeefer 18y ago
We actually took the opposite approach a couple of years ago and designated a specific "no meetings" day every Tuesday for the development team (and so many people work remotely on Fridays that it's effectively a meeting-free day as well).
328.
by akeefer 18y ago
In my work, an IDE is beneficial in two main cases. First of all, for someone new to a language or library, auto-complete and instant doc lookup help you figure out what's available to call and what the various methods and classes do. Tha
329.
by akeefer 18y ago
I think you read too much into that . . . I think Ruby is a fantastic language, and my point is merely that people don't use IDEs for languages like Ruby and Python because the IDEs for those languages are comparatively poor. If there was a
330.
by akeefer 18y ago
For anyone who's worked extensively in both worlds, I think it should be obvious that a great IDE is better than a just a text editor. Yes, Emacs and Vim are amazing tools, but no, I'd never go back to Emacs after having used IntelliJ ID

More ›