Voice of the DBA

Tag: software development

  • Is Software Engineering Dead?

    Software Engineering
    Are textbooks like this obsolete?

    Is Software Engineering dead? It’s a premise that’s in this article from Bloomberg. It calls the job a career dead end where job prospects decline after one reaches 35 years of age. I think that’s a naive view of the industry, despite the quotes from Craig Barrett and Mark Zuckerberg. While the best of the best might peak in their careers at the same age as many athletes, that doesn’t imply that the career choice is a poor one.

    There’s a discussion on Slashdot as well, and I was struck by a few of the comments, which seem to suggest that if you are still just a “software engineer” at age 40, you aren’t very good at your job. It seems that some people seem to think that everyone in this business is constantly looking to move to a new job and advance into management or they aren’t successful . I saw analogies with other industries thinking that same thing, that experienced people would not still be doing the same job after 20 years.

    That seems crazy to me. So many people in various industries continue to improve at their jobs, and do the same work for decades. Carpenters, doctors, accountants, all continue to improve their skills over time, and while some may more into management or open their own firms, many will continue to do their same jobs until they retire. And they’ll enjoy their careers.

    I don’t deny that ageism exists, and that older programmers often can’t, or won’t, work as many hours as younger ones, but that doesn’t mean they aren’t worth their salaries. Good, experienced programmers produce better code, with fewer bugs. Once managers learn that working more hours doesn’t equal better code, or even more code, the entire industry will start producing better applications.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Being Responsible for Code

    I read this great account of how Facebook releases new code, and found it to be very interesting. Apparently the entire FB site compiles to a single 1.5GB binary at this time. That in and of itself is interesting, but their deployment strategy caught my eye as well. They use bittorrent to deploy the large file to all their servers. Very creative and interesting look at things from one of the largest web sites in the world.

    The process is interesting, but one of the comments caught my eye. It includes a quote from the article:

    developers must be held responsible
    I’m sure many DBAs wish developers were held responsible for issues.

    I know there’s no shortage of developers that make mistakes and don’t want to have responsibility for the code they release. I like the idea of tracking these metrics, and letting people’s actual performance being a part of their evaluation each year. Not trusting the manager’s memory, or the recent complaints from co-workers, but actually looking at the relative mistakes being made. This leaves out scale, but I’m not sure the scale of the mistake is as important as the frequency.

    However this is a double edged sword. Some people will perform worse if you place them under this pressure and may find it too stressful an environment. If you don’t have the same pressures as a company like Facebook, you might end up driving away good employees that could fit in elsewhere.

    My recommendation would be that you hold people accountable for their work and use metrics like this to actually track that back to specific incidents, but that you use this as only a portion of someone’s evaluation. Track other measures available that help you determine if a particular worker is contributing value to your company outside of the bugs they might have in their code.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Tabs or Spaces

    Obfuscated Code
    Hopefully your code doesn’t get formatted like this.

    An argument among developers that might rival the NULLs/No NULLs debate, or even the comma appending/prepending items in T-SQL might be tabs versus spaces. I was engaged in a debate recently with a developer on this very topic, with this person insisting that tabs were the proper way to handle indentation in code, and my insisting just as hard that spaces were the way to go.

    Actually, I should clarify, I think that tabs should be inserted into code as spaces, so that a consistent layout can be maintained. Most tools allow for this, and while I have never worked in a place where the tab/space ratio was entirely consistent among all those writing code, I have found that using ASCII 32 is preferable to ASCII 9 when files are shared among different people.

    Am I right? I don’t know that I’m right, but I have found that spaces result in less issues, and easier to read code over time as more and more developers work on a project. Invariably spaces creep into code, and when they mix with tabs, the visual layout of the code can vary wildly, depending on the configuration of the developer. I understand that indents and alignment differ, and using a mix of tabs for indentation and spaces for alignment can work. I just feel that this is an additional level of conformity that will never work well for most team projects.

    There are all sorts of arguments for tabs, for spaces, even for saving the planet. The one thing I know is true: the only programming project with no disagreement whatsoever on code formatting is the one you work on alone (from Coding Horror). I also love the concluding sentence in that post (since I agree with it).

    With that in mind, I do think having a standard makes sense, and while the standard might annoy a portion of your developers, overall they will get used to it and be more productive than having no formatting standard at all.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Great Developers

     

    Are you on track to be a great developer?

    Is a great software developer worth 100 average ones? On one hand I think there are some good arguments that it’s not true. One developer certainly can’t write the amount of code that 100 average ones can. However there’s another way to look at things. A great developer can do things that the 100 will never think of, or never consider. He might not write the code that does as many things as 100 people, but I think a great developer could easily write code that performs a hundred times faster than the code 100 developers write.

    That’s why you always have an open position available for a great developer. If one is available, and they rarely are, you hire them if they want to work for you. You can always find things for them to do, and they can make improvements in code that your other 5, 10, or 20 developers will never come up with. I’d make sure they fit in your team and get along with others. You can get less work done if you have someone that is too difficult to deal with or too critical of others. While a great developer can accomplish things that others can’t, or won’t, they can’t do all the work.

    Ultimately I think that managing great developers is hard, and they are unlikely to stay with your company for a long period of time. However they are rarely available, and for a few years, they might jump start the evolution of your software, and potentially build something that makes your software great. I’d always have an open spot in my team for a great developer, and hire them as soon as they came available, if I thought they would fit in well with the rest of the team.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.