Software Engineering in Practice

  • Comments posted to this topic are about the item Software Engineering in Practice

  • There are some companies that add the term Graduate, Junior, Trainee, etc. to the role of new starters (to the field of computing). Occassionally this involves ensuring that theorectical foundations exist, if they do not already, and practical application is guided.

    I see more and more companies avoiding this step or paying lip service to it.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Exemplified by this fierce debate at TDWTF:

    http://what.thedailywtf.com/t/junior-developer-woes/8707

    "As a growing company, we recently hired a new Junior developer. The guy didn't have any work experience, but he did have a fresh university degree in CS, and he did well in the interview. In order to help him get his feet wet, we gave him some simple one-off projects to work on. We didn't have time to review his code, but the projects were so simple that they a university grad should have had no problem with them.

    It turns out that this was a terrible mistake. He left the company after about two months of development. Then, the trouble started. As we began using the projects he had worked on, nearly every single one had some critical bug or flaw that prevented it from being used. This forced us to scramble to start fixing his work."

    plus moaning about the quality of the work etc etc.

    I am with the general thread consensus that the error lies with the poster or his company. 'We didn't have time to review his code, ...' You cannot assume that he will do what you want. How will you develop any house style if you let a fresh out of college person just do what they see fit with zero guidance? This was a screen scraper, a tricky thing for anyone to do. I'd freely admit I knew NOTHING about real programming, despite many years of coding, when I left uni. I put my heart and soul and whole experience into showing new devs what to do and take pride when they exceed what I can do in some area. It's the only way, even if it's not exactly formalised or even encouraged here.

  • Heck, I'd kill for some kind of apprenticeship/mentoring program. I'm perfectly comfortable hacking all this out on my own, but I know there's AN AWFUL LOT I'm missing.

    I use techniques that are less than optimal but they work well enough at the scale of our environment. But I also know there are better methods out there and as I learn them, I implement them. I take care to structure things to make refactoring as painless as possible.

    It would be nice to have someone around I could bounce ideas off of and could help me fill in the gaps. Far too often web crawling yields little more than quasi-religious rants on why X is "evil" or just code snippets that leave me practically yelling "Why? WHY are you doing it that way?" At least here folks are willing to explain things given the limits of an on-line forum. The various "Stairways" have been invaluable as they cover big topics in manageable chunks.

    But even so, that's worlds different from having a living, breathing body you can talke to in real time.

    ____________
    Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.

  • After decades of programming, some of the basic thought processes come so natural it is easy to forget that everyone doesn't have them.

  • Iwas Bornready (3/30/2015)


    After decades of programming, some of the basic thought processes come so natural it is easy to forget that everyone doesn't have them.

    +1

    Always been an advocate that doing the basics well creates better business systems than quick and dirty.

    Very few places seem to weigh in the cost to the business of rework.

    Worked in a data warehouse group for about 20 years.

    I don't ever recall our group having to go to the execs for an 'emergency migration' to fix an issue.

    We even had many times where users would ask for an enhancement, only to find out it was already there.

    It just seemed like their next question / additional data, so we included it as part of their original request when we coded.

    Usually it was noted in our announcement of the new measures and dimensions, which we only sent out to the SMEs, and they failed to pass it down to their users.

    Apprentice type approach is good for both - the senior people may find out about something new, while the new ones get a great foundation.

    The hardest part of this is selling this in many places.

    Those in charge may often say the developers are always overloaded, we don't have time for this.

    If they dropped down to 'what are they working on', conversation might start in a different direction.

  • If you are serious about quality you will provide some kind of leadership and supervision to your new hires; especially the new-hires. Most universities are businesses now and you can't trust their product like you could in the past. For them it's about enrollment (revenue). I treat MBA's in IT with almost as much skepticism as the undergrads. Most grads come out only proving they can take tests well. Critical thinking and problem solving skills? Show me.

  • I see a fundamental problem here, and that is the size of the organization. I've never worked in a large enough shop to have more than one or two programmers, and never more than one DBA except for my first job (until my boss left), so the concept of apprenticing someone is just a non-starter. My first IT job was working for a realtor developing a mailing list system, then I moved to an actuarial company making a mail/merge system for creating contracts, followed by expanding their billing system to produce a greatly improved invoicing system that included printing tax forms and bar code scanning, all in dBase III. And my education was programming theory courses, COBOL courses (and other languages), and a database course (which didn't mention dBase, it was all theory).

    A solid grounding in theory doesn't mean that you won't benefit from an apprenticeship, but at least you won't inhale too much water when you're thrown in the deep end. I've tried to pay that forward when I've taught database classes by starting out with set theory and normalization, and it seems to have worked well: set a solid foundation and everything built on top of it will be stronger. I think this is also an on-going problem: theory doesn't seem to be taught as much, everything seems to be taught in an "X"-language context and people seem to have problems transferring the theory to "Y"-platform.

    -----
    [font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]

  • lshanahan (3/30/2015)


    Heck, I'd kill for some kind of apprenticeship/mentoring program. I'm perfectly comfortable hacking all this out on my own, but I know there's AN AWFUL LOT I'm missing.

    Ditto.

    BTW, that's some of what we try to do here. Give you a place to bounce ideas off of someone.

  • Wayne West (3/30/2015)


    I see a fundamental problem here, and that is the size of the organization. I've never worked in a large enough shop to have more than one or two programmers, and never more than one DBA except for my first job (until my boss left), so the concept of apprenticing someone is just a non-starter.

    ...

    Certainly an issue. Professional groups and sites like this can help, but you need to know how to find them. We don't do this well.

    ...

    everything seems to be taught in an "X"-language context and people seem to have problems transferring the theory to "Y"-platform.

    I struggle with this. I think SQL is different from OOP or procedural development, but most of the rest is just syntax. Certainly there are tricks with aync web work and javascript v think clients, but languages are just implementations. You should be able to easily move from one to the other with a little effort.

    I think the key is you need to regularly ask people how they might do things differently. Or how they'd improve your code.

  • I ran across a review of a developer's first year at a company. The company is endjin and the poster describes their first year as a "software engineer apprentice," which is an interesting way to look at one's early career.

    I read the provided link and noted the 'apprentice' is working within the MS .Net ecosystem.

    Certainly many of the lessons learnt by the apprentice are valuable ones, regardless of the specific development environment. It does seem unfortunate, however, that this particular apprenticeship is being spent using a framework whose future appears increasingly uncertain. One might even argue .Net is now a legacy framework, at least in the web development realm, having been supplanted by the HTML5/JavaScript/CSS3 triumvirate.

    Perhaps the apprentice had to accept whichever opportunity came her way; we can't always pick and choose our path. Yet were I to take up an apprenticeship at my hoary age, I would attempt to guide myself toward more current technologies, so as to avoid acquiring parts of a skill set which are already dated.

  • GoofyGuy (3/30/2015)


    I ran across a review of a developer's first year at a company. The company is endjin and the poster describes their first year as a "software engineer apprentice," which is an interesting way to look at one's early career.

    I read the provided link and noted the 'apprentice' is working within the MS .Net ecosystem.

    Certainly many of the lessons learnt by the apprentice are valuable ones, regardless of the specific development environment. It does seem unfortunate, however, that this particular apprenticeship is being spent using a framework whose future appears increasingly uncertain. One might even argue .Net is now a legacy framework, at least in the web development realm, having been supplanted by the HTML5/JavaScript/CSS3 triumvirate.

    Perhaps the apprentice had to accept whichever opportunity came her way; we can't always pick and choose our path. Yet were I to take up an apprenticeship at my hoary age, I would attempt to guide myself toward more current technologies, so as to avoid acquiring parts of a skill set which are already dated.

    While I won't argue about the aging nature of .NET, the apprenticeship aspect should be structured around teaching reusable skills and patterns that can be moved elsewhere. If the apprenticeship is purely around rote coding practice buried in a specific language, then yes - that might severely limit the usefulness.

    ----------------------------------------------------------------------------------
    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

  • I think there is merit in an apprenticeship style approach. Anything that gets people more exposure to actual work environments, real-life problems, and how real life workplaces and teams interact would be a huge improvement, both at preparing people for their careers, and at potentially providing a good basis for assessing who would and would not be a good employee.

    That being said, it would not necessarily help with the specific problems you note, Steve. As others have noted, a lot of the places with the biggest problems you have described tend to have very small IT teams. They may have no DBAs at all. The programmers may be self taught. Even where they are not, they were often hired by people with a non-technical background and no good way of evaluating the quality of the person they hired.

    I think apprenticeships would get talented people better experience, and help them find the right career path and differentiate themselves from others better. But I think the results of that would generally be better job fits for the best of candidates, and more hiring success for the biggest of companies, and for dedicated IT firms. But I'm not sure it would change much of what goes on outside that sphere.

  • True, but not everyone starts in a small shop. Plenty of people change jobs, and the more we apprenticed, the more talented people that would move on to other positions.

    I think there will always be the fly by night IT people that work in small companies and that's fine. Ultimately some will do great, some will make a mess, some will be fine, but the business will have to live with the talent it hires.

  • Matt Miller (#4) (3/30/2015)


    While I won't argue about the aging nature of .NET, the apprenticeship aspect should be structured around teaching reusable skills and patterns that can be moved elsewhere. If the apprenticeship is purely around rote coding practice buried in a specific language, then yes - that might severely limit the usefulness.

    Matt, you're spot on.

    I read the apprentice's blog, link to which Steve Jones supplied. The apprentice discussed acquiring skill sets both external to, and part of, the MS development environment. I think the former will continue being of considerable value to her; the latter less so, as every technology has its 'sell by' date, with .Net arguably 'vieux style' (at least for Web application development).

Viewing 15 posts - 1 through 15 (of 47 total)

You must be logged in to reply to this topic. Login to reply