1,498 reputation
bio website publicvoidlife.blogspot.com
location Boston, MA
age 35
visits member for 4 years, 7 months
seen Feb 5 at 14:33

Enterprise application developer and software architect, focusing primarily on the Microsoft stack and web platform.

I currently work as a consultant in Waltham, Massachusetts. (A job I found on Stack Overflow Careers, thank you very much.) I'm interested in lots of extra-curricular software development activity (user groups, conventions, panels, etc.) as well as general local geekery (gaming, geocaching, anything fun).

Career aspirations involve becoming a better developer, a better architect, and maybe even getting published once I find something about which to write.

comment Should the design take longer than code development?
This reminds me of one of my favorite quotes: "The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time." - Tom Cargill
comment Programming Test
Maybe have the candidates fix the system you're using? Or have them develop a new one?
comment Should I intentionally break the build when a bug is found in production?
@JohnBuchanan: What are the tests meant to validate, if not that the software is doing what it is supposed to do? (That is, that it meets the requirements.) There are, as you state, other forms of tests outside of unit tests. But I fail to see the value in unit tests which don't validate that that software meets the needs of the business.
comment How can I learn practical applications of software engineering principles?
@justausr: The best resources I've found for personal growth in the trade (second only to experience on a good team) are books. I linked to one, jgauffin linked to another. These books will internally reference more books, and so on. Martin Fowler, Bob Martin, Kent Beck, etc. There's no shortage of great books from great authors. Don't just read them, apply them. Read a little, think about it, blog about it, write code to demonstrate it, read more, rinse, repeat.
comment Keeping an MVC model loosely coupled from the DB?
@Industrial: Keep in mind also that the repository methods don't have to just be CRUD. Lots of intelligence can be baked into that code. A lot of the more complex ones can have a lot of internal code which transforms data from the database. Or, if the complex ones involve many trips to the database, then for performance gains you can put the logic in a stored procedure and the DAL method just passes through to that procedure and translates the results into models.
comment Keeping an MVC model loosely coupled from the DB?
@Industrial: For example, if you use an ORM, then that ORM would be referenced by your DAL (which is isolated from the domain models) and would transform your models into data access accordingly. Or if you do direct database access with manual SQL, you'd do that in your DAL's repository methods and translate the results of the SQL queries into domain models before returning them.
comment Keeping an MVC model loosely coupled from the DB?
@Industrial: There are a number of ways to connect models to persistence, but so far the only method I've found which truly satisfies my desire to separate concerns is to have repository interfaces in the domain which are externally implemented by a DAL. The repository methods accept and return domain models, and internally converts between those and any generated database entities. (To be honest, I haven't done this much in PHP.) So you can use a DAL framework to auto-generate all your DB CRUD, etc. and then write your repositories as an interface between that stuff and your models.
comment When do you start documenting the code?
@Graham Lee: True. But many times a meaningful name isn't enough. A short paragraph can be warranted to explain why something is happening a specific way. The code may very well express what it's doing, the names may very well express all the players, but if the deeper meaning isn't captured then a comment is most definitely warranted.
comment Is there an agile project management technique for developing innovative software systems?
"The development is innovative since we don't know how to develop it" - Best definition of "innovative" I've ever heard. Our marketing department is going to love that one.
comment Advice: How to convince my newly annointed team lead against writing the code base from scratch
@Mark Canlas: Absolutely. And that's where a lot of developers (even very experienced ones in many cases) lose their grip on the overall business. It has to have actual tangible value for the business, and very often the existing product has that value. Though one argument I always hate from the business is "we already spent money on this, so we need to use this." Sometimes, as in the case of my last job, a decision like that drives them into the ground. It's neither "always re-write" nor "never re-write." As you said... balance.
comment Advice: How to convince my newly annointed team lead against writing the code base from scratch
@Mark Canlas: It's kind of funny actually, because I'm often a proponent of re-writing. I hate legacy code :) But I also understand that if I can't demonstrate added value to the business, the re-write shouldn't happen. My opinion needs to be backed by numbers.
comment Versions of .NET in an Interview
@Carson63000: Another good one would be, "What feature or features are currently not present in .NET, and how do you think it could benefit from them?" That one would show knowledge of the framework while at the same time show that they can think (and indeed have thought) beyond what's currently there or currently taught in some cert course or something.
comment When should I use—and not use—design patterns?
@user374980: Agreed. The patterns themselves are essentially language-agnostic, but different languages will have different details on the best way to implement them. Simply porting an implementation from C# to, say, Ruby may be ill-advised. Attempting the same to Lisp is downright silly :)
comment What is the definition of “technical debt”?
To expand on this a bit... The idea is that we can "pay a little now" to design it properly, or "pay more later" to retro-actively fix it (since changing code is generally easier in the design phase than in the support phase). Thus, much like credit debt, it does accrue interest. In the end, more is paid to get something done quickly (like buying something before one can afford it with credit.)