New Masters Program in Software Engineering



  • @Polygeekery said:

    Once again, no offense meant to you or your career. I am just speaking from my experience.

    None taken. I know it's a weird choice -- weirder still when you have to deal with some of the professors that make @blakeyrat stand out like a shining pillar of reason and good manners.

    I am in the process of starting up a new master's education in a software engineering topic. Are there any topics we should definitely teach that would make our students more employable? Are there any values (for example a craving for learning, as you pointed out) that we should focus on instilling, or are there any particular ways of working that would make them more employable?

    I mean, I can have them j*** off with UML and metamodels for a whole semester but that will not make them more employable than your self-taught guy that you mentioned, so how, in your mind, can I get our students to be "ahead of the game" when they graduate?



  • @Mikael_Svahnberg said:

    I mean, I can have them j*** off with UML and metamodels for a whole semester but that will not make them more employable than your self-taught guy that you mentioned, so how, in your mind, can I get our students to be "ahead of the game" when they graduate?

    I think you should introduce them to source control and effective debugging if they haven't already encountered those. I think @ben_lubar's university has certain courses where you submit your assignments to centralised source control.


  • ♿ (Parody)

    I moved these at the request of the previous topic's OP.



    1. Source Control. Various kinds.
    2. Time Management. Give them a semester project, with gates. Don't just grade on the final product, but on progress made throughout the semester.
    3. Clean Code. OMG seriously. Take points off for creating code that doesn't document itself.
    4. Budget constraints. Let them into code with multiple things wrong, but they're paid to only fix X. Give them a budget and have them roleplay with customer. Give them code that already does what the customer is asking for, and let them find out the hard way.
    5. Hard to maintain code. Give them a POS code base repeatedly. Let them get that out of their system now. It was a major culture shock to have to maintain impossible code.
    6. Documentation. Have them write proposals, designs, have in class discussions where other students can criticize their choices.
    7. Review code. Don't just have them make stuff, have them review stuff too.
    8. Have them have to document their work. Grade them on whether they can track their work, cost their work, and give accurate assessments of what they did. Make that a part of a big project that includes various things I mentioned above. Combine this with the budget constraints and grade them on what margin they made.


  • @Mikael_Svahnberg said:

    weirder still when you have to deal with some of the professors that make @blakeyrat stand out like a shining pillar of reason and good manners.

    Oh god don't remind me. That fucking old witch. She was everything bad you can have in a person and in a professor. 5 minutes with her and you literally wanted to punch her in the face. And I had to obey every one of her nonsensical whims for 4 months.

    Anyway, every experience I've had with "software engineering" has just been a long string of meaningless buzzwords, cargo-cult rules and silly UML diagrams. So, try not doing that I guess.


  • Grade A Premium Asshole

    I had these moved as I feel like others might want to chime in on this. There are quite a few people here who hire and recruit people: @accalia, @cartman82 both come to mind, but I know there are more.

    @Mikael_Svahnberg said:

    I am in the process of starting up a new master's education in a software engineering topic.

    Wow. That is quite the undertaking. Well, before I answer, keep in mind that I speak from the point of view of someone across the pond. We have very few horribly smelly fish dishes. YMMV and all that. ;)

    @Mikael_Svahnberg said:

    Are there any topics we should definitely teach that would make our students more employable?

    Make certain that your students know what happens at the lower levels. Here in the US there are new degree programs that are catered to web application developers. That is all well and good, but those who went through those programs have no educational experience with lower-level languages and processes. Once the code hits the interpreter, it becomes magic to them.

    @Mikael_Svahnberg said:

    Are there any values (for example a craving for learning, as you pointed out) that we should focus on instilling

    Hmmmmm, a person is always at their bests when they follow their passions and not the biggest paycheck. I am not sure how a group of teachers with a few hours of exposure to the students per week can help them along this path, but it is worth mentioning.

    Teach them how to learn and how to solve problems for themselves, scratch their own itch as it were.

    Many fresh graduates are terrified to fail. Everyone fails, fail gracefully, learn from it so you are less likely to do it again. Own up to your failures.

    Teach them the why. The why is vastly more important than the how. If you teach people how to do something, you create drones and automatons. If you teach them why, they can think for themselves and reason through their own problems.

    @Mikael_Svahnberg said:

    but that will not make them more employable than your self-taught guy that you mentioned, so how, in your mind, can I get our students to be "ahead of the game" when they graduate?

    Want to hear something amusing? I am an atheist with no college degree and I teach part-time (1-2 courses a year) for a Catholic university. One of the things that we are starting to do is for one of their business classes we bring in local NFP's and community groups and they bring us their real-world problems and we have the students work as a whole to solve those problems for them. It may be marketing issues, awareness, community involvement, etc. The students (who are all in an adult education fast track program) all rave about how much they learn and how enjoyable the classes are.

    I say you attempt to institute something like that. Synthetic problems breed synthetic, predictable, solutions. You need to get the students involved with real-world problems that real-world businesses and organizations are experiencing. Perhaps you could tie it in to some sort of community outreach or small business program? They need to get some curve balls.

    I was a horrible student. Structured learning just never worked for me. It all seemed so arbitrary and manufactured. I would have loved a chance to work on real world stuff. I like to be out of my comfort zone. (yes, I realize that is an oxymoron) I took the teaching job because I was such a horrible student. Teaching was about as far outside of my comfort zone as I could get and I believe that we only develop personally when we get outside of and stay outside of our comfort zone. I have no problems with public speaking, never have. That first night though, I was...petrified. Now, it is relatively easy and enjoyable. I get the students engaged. I teach them in such a way that they help me teach them. I get them talking and they will tell me where they struggle and then we can work on that.

    @Keith said:

    I think you should introduce them to source control and effective debugging if they haven't already encountered those.

    Absolutely. By the second semester of CS, they should be working with and submitting assignments through source control. They need to be familiar with using some form of it before they graduate.

    @xaade said:

    Review code. Don't just have them make stuff, have them review stuff too.

    Absolutely. Both parties would learn a lot from this. Sometimes things seem fine to you, or you cannot see where the problem is, but another person can look at it and immediately see the issues.

    As for the rest of @xaade's points, tie in some business classes to it. Unless they continue on to academic pursuits, they will be using technology to solve business problems. If they know fuck-all about business, it is much harder to hit the ground running. Even if they move on to academics, they will still have to work within budgets, etc.


  • FoxDev

    @Mikael_Svahnberg said:

    Are there any topics we should definitely teach that would make our students more employable?

    i can think of a few.

    1. make sure students are fluent in at least two unrelated languages. Preferably one with C like syntax (JAVA and C# seem to the be the big two in that field these days) and one with a non C type syntax (i'd personally go with Python for that category)

    2. avoid teaching esoteric or "educational" languages. use the ones that are encountered in the real world.

    3. documentation, and not just how to make UML diagrams (although they should be able to produce those too) i mean how to take an API and document not just the what of how it works, but the why and what assumptions about program state it makes. stuff like that

    4. public speaking. students should have public speaking experience because they're going to need to present their ideas in a group setting in the workspace and kn owing how to do that eloquently is important

    5. debate: students should know how to debate properly. this is important when you are trying to plan a project with a group of peers.

    6. Interviewing. Have a class where students prepare for an interview, and make their final exam be an interview! (extra bonus points for partnering with local businesses so the students are interviewing for actual jobs and can actually get hired as a result of the class!)

    7. critical thinking of legacy code. provide students with legacy code in a language they haven't worked with before (VB or javascript, or something like that) and ask them to make localized changes to the code.

    8. testing. automated and manual testing. why it's important, how to design to make testing easier and more effective

    9. hardware/network design. from systems programming to web developers. in order to be effective at your job you need to have an understanding of at least the gross mechanics of the layer of technology you are building your work on top of. no need to be an expert able to make the next great breakthroughg in processor design, but need to understand the rough mechanics of the internals of one

    10. Source control. not just checking their code into their private repo, but branching merging working with upstream and downstream sources

    11. projects. need to be able to work together to accomplish project on schedule. will have to work carefully with this one to make it so slackers cannot be pulled along to greatness by their peers, but also don't pull their peers down into oblivion

    12. design patterns. Not just what they are but why they are. what is the factory pattern, what problem is it built to solve and when should it be employed. I see to many people that over architect to the moon and back because they are cargo culting design patterns not understanding the why.

    13. experience with different operating systems - it's a huge bonus for programmers to be familliar and comfortable in multiple operating systems. they can have a favorite of course but they should be able to work in Windows, Mac, and Linux (both through the GUI and the CLI)



  • I can't exactly speak to hire-ability.... but here are some thoughts.

    One thing that seemed missing from @xaade's list is testing. I taught an elective on compilers (think juniors/seniors and a few grad students) on two semesters, and I tried for a while to make that a part of the projects by making them submit test cases along with the code, but eventually "gave up." If I ever teach again I'd like to revisit the idea, but the problem is I'm not exactly sure how to grade them, and all my ideas would require a bit of infrastructure work I didn't have time to do.

    (I think the ideal would be some combination of: coverage over my solution's code; coverage over the student's submission; number of bugs the test suite evokes in other people's submissions. Bonus points for finding bugs in my solution. :-))

    On the subject of grading, I'd kind of like to set up a system for doing largely automated grading as follows:

    • Divide your grading test cases into three parts
    • Any time before the deadline, the students can submit the current version of the code. (Perhaps by checking into VCS.) It will automatically compile and run the program on the first and second parts, delivering:
    • A report about any problems encountered during compilation
    • For the first set of tests, delivering a full report of any failed tests
    • For the second set of tests, deliver only #passed/#failed. If people want more info, they can come talk to me. [I'm not totally sold on the purpose of this category and whether it is useful.]
    • For the third set of tests, deliver no information
    • After the submission deadline, then deliver information about the set of reserved tests.

    The goal is to provide at least some information about how people are doing while they still are capable of improving things, but trying to prevent them from over-specializing their programs to the test cases.

    Edit: oh yeah, and another aspect of the tests-as-part-of-the-project is having people make an initial submission of test cases before the main deadline (trying to encourage at least somewhat of a test-first dev style, which may be a bit dogmatic but whatever).

    @Polygeekery said:

    By the second semester of CS, they should be working with and submitting assignments through source control.
    I am incredulous how little this happens. I think it should be done in the intro programming class. But about half the people in my compiler classes did not have VCS experience. What's really fun is to ask the following sequence of questions:

    • "How many people have been working on your project, get something kinda working, so you back up your folder to project-with-thing-working/" -- you get nearly all hands up
    • "How many people have wished they had done that at a point at which they didn't" -- the vast majority of hands will stay up
    • "How many people have used VCS" -- and half the hands go down

  • Grade A Premium Asshole

    Reverse engineering practices would be a huge boon, so that the first time they encounter a poorly documented POS they know how to get started. Inspecting elements, tracing things through Javascript logic, working with something like WireShark or Charles to see how the data flows in and out of a web application, starting at the user's end and tracing things back through the logic to find the problem. So few fresh graduates have any freaking clue how to do this.


  • Grade A Premium Asshole

    @EvanED said:

    I taught an elective on compilers

    The best of the best are people who have taken such classes. The best person I have ever worked with (friend and occasional business partner) was still in school when taking CS classes still meant that you would be building a compiler as part of a keystone assignment. That seems to have went away. Wherever the student's education stops, the rest of it may as well be magic. The new Informatics degrees are releasing students that have no freaking clue what happens after the code hits the interpreter and that is just way too high of a level to stop your learning.



  • @xaade said:

    1. Source Control. Various kinds.
    2. Time Management. Give them a semester project, with gates. Don't just grade on the final product, but on progress made throughout the semester.
    3. Clean Code. OMG seriously. Take points off for creating code that doesn't document itself.
    4. Budget constraints. Let them into code with multiple things wrong, but they're paid to only fix X. Give them a budget and have them roleplay with customer. Give them code that already does what the customer is asking for, and let them find out the hard way.
    5. Hard to maintain code. Give them a POS code base repeatedly. Let them get that out of their system now. It was a major culture shock to have to maintain impossible code.
    6. Documentation. Have them write proposals, designs, have in class discussions where other students can criticize their choices.
    7. Review code. Don't just have them make stuff, have them review stuff too.
    8. Have them have to document their work. Grade them on whether they can track their work, cost their work, and give accurate assessments of what they did. Make that a part of a big project that includes various things I mentioned above. Combine this with the budget constraints and grade them on what margin they made.

    numbering my expansions on the above as numbered above.

    1. Definitely, very achievable: several assignments, each in a different source control repo, they must check out the code or similar, create a branch or similar to differentiate their submission, and check in their finished work or similar to submit. Those 3 steps required to pass, bonus points for multiple, meaningful and well documented checkins as their work progresses.
      a. extra credit if you set up an empty TeamCity or other build server instance and they create a functional build configuration for the project, extra extra credit if it runs the unit tests. Being able to run a build server is a MASSIVELY employable skill.

    2. Time management - good suggestion, don't be afraid to throw spanners though, they should have learned time management in their study up to this point, time management in a shifting environment is a really important skill too.

    .5. This is really important. Learning to accept the shit you have to work with is a big part of being a good employee, give them a functional codebase (in source control) at the start of the course, provide change requests in a standard format at regular intervals and at various severities. Throw the regular spanners like unhelpful "Burger request form is broken!" tickets, requests for stuff that's already there etc.

    Additionals:
    Hands on with development methodologies, have a large application code base (because we haven't already asked you to prepare enough...) set up a kanban board or similar with hundreds of very simple tasks, changing the color of a label from blue to green that sort of stuff. have the whole class do a scrum meeting of sorts and dole out the work to everyone, and tell everyone to record the time it takes them, each task should be about 10 minutes long from opening the source code. show them that all those tasks done by one person would take days/weeks/months but the class working together achieved it in an hour or 2. It really highlights the power of these development methodologies, but try and highlight the flaws if you can too.

    True error handling: start with an application that catches every exception and silently writes it to the console, exactly and entirely the error handling I and I assume most people were taught during degrees. Tell them to rework the code to clearly inform the user of each and every error that is thrown, and where appropriate resolution options. Example: when a file cannot be found, offer to create it or browse for it.

    refactoring for Unit testing: give them an application which instantiates a database connection or similar external dependency in the constructor, but can otherwise be easily mocked, have them refactor it to inject that dependency, and then write unit tests that mock it.

    I'm sure we can come up with more than this, but there's only so many teaching hours you are going to have...


  • FoxDev

    hmm.... one thing i didn't mention before is:

    Encourage students to have hobbies related to their interests. I'm more likely to look on a candidate favorably for a programming job if they do something related to technology for fun.

    something like:

    • Participate in FIRST Robotics (you should anyway: it's lots of fun!)
    • Do development on the side, for fun or for profit
    • work on RC cars/heliflopters, ham radio, stuff like that.

    The list is actually very long and the reason i look for it is if you have a hobby like that it shows you are invested in, i'll call it, "Geekery" for more than just your paycheck and i'm betting that it will pay off for me in the long run.


  • Grade A Premium Asshole

    @accalia said:

    projects. need to be able to work together to accomplish project on schedule. will have to work carefully with this one to make it so slackers cannot be pulled along to greatness by their peers, but also don't pull their peers down into oblivion

    Source control could help so much with this. You could look back through the commits and see if some people are slacking off and others are busting their butt in order to keep a good grade. Be careful on the implementation of that or else you could end up in a LOC debacle like tech companies had in the 90's.


  • Grade A Premium Asshole

    @accalia said:

    Encourage students to have hobbies related to their interests. I'm more likely to look on a candidate favorably for a programming job if they do something related to technology for fun.

    I don't think this is something you could really do on the educational side. It is certainly something to look for when they are out in the real world though, as I have mentioned before.



  • @Keith said:

    certain courses where you submit your assignments to centralised source control

    Those would be the classes taught by Prof. John Tang Boyland. I've had a different class with a different professor where I was required to submit assignments as zip files with my name on them.

    [spoiler]Also, I have bad news for you about the UML thing.[/spoiler]


  • FoxDev

    @Polygeekery said:

    I don't think this is something you could really do on the educational side.

    can you make them have one on the educational side? probably not.

    but you CAN encourage them to have such a hobby, and provide resources to get started and to help them find others that are interested in the same sort of things.

    this one wouldn't so much be a class as additional support/resources and occasional subtle prodding that it might be a good idea.

    ;-)


  • Grade A Premium Asshole

    @accalia said:

    but you CAN encourage them to have such a hobby, and provide resources to get started and to help them find others that are interested in the same sort of things.

    Like a Raspberry Pi or Arduino club? Or your robotics club? Yeah, that would be really beneficial and I would certainly look more favorably on a candidate that had a track record of doing things like that for fun. As part of educational curricula, I am not sure it could be done though. But it would be great if they had the resources available and a structure in place to do so on their own.



  • Loads of good suggestions here: Reverse engineering, version control, testing and testability, documenting above the code level, code reviews, exposure to legacy balls of mud, and practical experience with software project management are all things that definitely should be in a CS program (of course, so should a couple of solid programming languages (if I had my dibs, I'd teach Python first, then a mixed assembler/C course for low-level stuff, and probably a recent C# rev if they really needed a modern C-family language, as well as exposing them to Clojure if a 'theory of CS' language was desirable) and a good understanding of the blinky-lights-box).

    I'll indulge in adding a couple to the list:

    1. Database design 101 -- relational fundamentals, basic 3NF, query authoring and joins, indexes, and SQL/code interfacing. SQLite is a fantastic tool for this -- it's widely available, light-weight, and has a solid base SQL dialect.
    2. UI/UX 101 -- find a good UI book for your students to read, have them go out and look at meatspace UIs, do some hallway-usability-study exercises, and a UI WTF hunt; also, there are some ethics issues to touch on here -- look at "UI dark patterns".
    3. Failure and error handling -- this is a topic that just doesn't get talked about; Lippert's four types of exceptions are a good place to start this discussion, as they're really four types of errors irrespective of the error-handing scheme you're using. This is also a good place to discuss API contracts and some basic failure-analysis techniques -- get your students thinking "What if the frobulator runs out of memory halfway through frobbing the widgets?" (Error-recovery strategy can also be discussed here.)
    4. Practical formal languages -- get them to understand not only basic computability and complexity, but how to use formal methods (grammars, schema) to parse and validate real-world data.

  • FoxDev

    @Polygeekery said:

    Like a Raspberry Pi or Arduino club? Or your robotics club?

    exactly that sort of thing!

    @Polygeekery said:

    As part of educational curricula, I am not sure it could be done though.

    Agree, but there is more that you learn in college and more that is taught than what is just on the Curriculum Vitae.

    @Polygeekery said:

    But it would be great if they had the resources available and a structure in place to do so on their own.

    this is what i was thinking of. provide the resources and encouragement to help them develop their hobbies and make sure the existence of said resources is well known and widely available.

    then you can watch them grow far beyond what can be taught inside the walls of the classroom.



  • CS101 is "introduction to Microsoft Word".


  • kills Dumbledore

    @tarunik said:

    UI/UX 101

    That's a difficult skill for a lot with the programmer mindset, but students definitely need to be aware of how important it is. I've known a few recent grads who write for other programmers and give a blank look when asked how a regular user would know what to do



  • BTW.

    Source control, doesn't mean submitting your projects using source control.

    It means knowing how to branch, fork, pull request, etc.

    As far as testing goes, you can have a class that's entirely based on TDD (Test Driven Development), but you also need a class that handles testing when your product was developed without that platform in place.

    As far as compilers and languages, those things should already be covered in the undergrad degree. If you have these classes in the master, you have a remedial master class. Doesn't look good for the degree, and it's something you need to go talk to the department and have fixed. Design patterns, public speaking and debate. All these are also undergrad courses.

    Again, if you have to cover these topics, you have to. If students leave a master degree without this knowledge, the degree failed.

    However, my personal opinion, your grad level courses should be project management related. Generic job skills should have been covered. If this is not the case, you really need to take some time to review your degree with the department/dean.

    You would also benefit from bringing in as many professionals into the classes as possible. If businesses want students that know these skills, they should invest in their local schools to ensure the skills are being taught.


  • Grade A Premium Asshole

    @tarunik said:

    Failure and error handling -- this is a topic that just doesn't get talked about

    Yes! @Mikael_Svahnberg asked about skills and traits to instill in the students: Get them to stop thinking about if their code will fail and have them think about when their code will fail. Expect failure. It may not fail right now, but two years from now some poor bastard is going to change something and there will be unintentional consequences. Plan for those now and save tons of time later.



  • All these suggestions are fine, but it's questionable how realistic is to cram all that into a limited time slots and budget you have available. It's easy to find new exciting ideas. The real question is, what should they replace and is it worth it?

    My perspective is limited to 3rd grade schools in a poor second-world country, so take it for what's it worth: the biggest failing I see in these juniors I've interviewed is disconnect from the real world.

    They all had some level of knowledge. Went through their exercises and mostly aced the exams. And then, it's like whatever they'd crammed during the semester had just faded as soon as the passing grade was filed in. For them, these subjects weren't real skills they will need in the real world. They were just another bullshit school exercise you game your way through and move onward.

    I remember speaking with another kid, who was just starting 3rd year in a different CS school (unrelated to the junior testing stuff, this was a family friend). He mentioned he had just passed "Visual Studio" exam and was starting PHP next semester (which is right now, actually).

    -- Oh really? So what, you were doing C#? ASP.NET? WPF or win forms?
    -- (he's looking at me blankly)
    -- Web sites? Desktop apps? Console apps?
    -- Ummm.... I'm not sure....
    -- Like when you click run, does it show like a black console screen or a graphical window? (I actually asked him this)
    -- Black screen, I think.... Dude, you know... the purple infinity icon. Visual Studio!
    -- Yeah... good job there, sport.

    It's the same thing with my intern. He tells me he had little clue what he was doing until he was actually given a real task and expected to deliver a product. His school assignments were just some bullshit tests he was breezing through, like he did through elementary school and highschool. It never occurred to him these were the actual skills he will need to utilize. That someone will actually pay HIM to perform, instead of the other way around.

    So, conclusion. I'd like to see applicants who have a better understanding what's expected of them in my company. How the subjects they learn actually relate to the real world. What's the point of it all. I'd like to see each student graduate with at least one open-sourced usable project. Something that is at least theoretically intended for other people's benefit instead (solely) for the grade. I'd like to be able to see their source code. I'd like to go into a bug tracker and see how they interacted with their users.

    You can't instill the love for the profession. You can't make them keep learning on their own. You can't teach them everything. But I'm pretty sure you could cram in something like this.

    What to take out? Not sure. Everything is useful to some extent. However...

    • If someone is teaching both C# and Java, STOP IT. Pick one. The same goes for other too similar languages.
    • Any non-IT subjects can go too. That shit is for highschool or the "liberal arts" knitting club.
    • The UML stuff is outdated nowdays, if you want to teach algorithms, better do it in real code (multitasking).
    • Electronics is related to computers, not so much to programming. Better leave that as an elective.

    That should leave enough room for more projects and real world stuff.



  • Oh and another thing. I actually sent this link to my juniors.

    Gist:

    The main thing they need to learn is self discipline. The discipline to always write the clearest code you can, the discipline to refactor code if it becomes muddy through changes later in development, the discipline to remove unused code and add comments.

    ....

    Keeping this in mind requires self discipline, because it means not stopping "when it works". If all the variables would have the wrong name the code could still function perfectly, but the code would be super confusing. The step from functional code to clear code brings very little reward in the short term: it worked already and after cleaning it up it still works. That is why discipline is required to take this step. That is also why doing an internship is so useful: a good supervisor is vigilant on code quality (even though the definition of "good code" might of course differ per programmer) and thus forces the intern or junior to always take that next step.

    Oh yes! You could see this in my "mettle testing" interviews too. All the kids stop as soon as the thing is barely working. No testing, edge cases etc...

    The same thing happened in production, with the kid we took. It's like the things barely work, so it's done. It helps when you make them maintain it in production. That at least got him thinking a little bit. He postponed deploy of his little project a few times for additional testing and bug-fixing, so that's hopefully a good sign.

    Note that no one ever learns this completely. No matter how good they think they are. I get sloppy too. But it's important to see this tendency in our habits and at least strive to improve.

    What can schools do about this? Little, the way I see it. Maybe someone can think of some clever tactic, but I doubt it.



  • It would be really interesting to teach ANSI C and C# 4.5 side-by-side. Write the same program in both and compare the code length/runtime/etc. Then ask the students which they prefer, and any that say ANSI C, flunk them immediately.



  • Everyone's outlined all the technical areas that need strengthening, but only a few people have identified missing soft skills. Soft skills are hard, coming from a highly technical background. A few that come to mind, that I would have loved to have had as an entry-level employee, are:

    • Project Management in a Management and Communication Vacuum. You answer a support call from a client and find out they were sold $MASSIVE_FEATURE_XYZ, which does not yet exist, and they need it by tomorrow. It is your job to explain to them that the salesperson lied to them about the availability of said feature, but you can't make yourself, the company, or the salesperson look incompetent in the process*. Good luck.
    • Walking on Eggshells While Juggling Chainsaws. Sometimes, management will give you conflicting directives or no directives, and you won't hear anything unless you screwed up, in which case you'll get an earful. Naturally, there will be no documented policies, so there is never any safe course of action. Additionally, what is the right course of action today may be taboo next week, and nobody will tell you until after you screw up. What do you do?
    • Comebacks. Management assumes that developers are overpaid, whiny, prima donnas (even though their own developers are paid at least $30k below market), and thus their opinions about the codebase and product are invalid. Any complaints about an unmaintainable codebase and a broken schema that can't change without a year plus of refactoring will be countered as not being profit-generating work. How do you counter that counterargument?
    • Politics. If you work too hard, you might be seen as a threat and others may try to get you fired. Someone might also work less hard than you do but gain more clout and responsibility due to charisma/sleeping with the boss/etc. How can you make sure your voice gets heard?

    *Quote from one of my former coworkers: "I love my job. My job is telling people they aren't gonna get what they want."


  • Grade A Premium Asshole

    Yeah, the proper course of action when you encounter the need for those skills is to polish your resumé.



  • @tarunik said:

    if I had my dibs, I'd teach Python first, then a mixed assembler/C course for low-level stuff, and probably a recent C# rev if they really needed a modern C-family language, as well as exposing them to Clojure if a 'theory of CS' language was desirable

    I was going to reply to this earlier, but didn't get around to it. Given your other languages, I don't like your choice of Clojure. Python already serves as a representative of the dynamically-typed languages, so Clojure is mostly getting you pure functional. But if you were to pick ML or Haskell instead, you not only pick up the pure functional category but also a language with strong type inference capabilities, which is otherwise lacking from your list. I feel like there's a decent chance more features from those languages will be "imported" to more traditional languages in the future (see the growing popularity of things like C++11's auto for a much weaker type inference feature being imported to many more C-like static languages) and I'd consider exposure to such a language to be pretty important; from the standpoint of a software engineering degree, I suspect that both O'Caml and Haskell are more popular than Clojure, though I've not seen data on that.


  • FoxDev

    On the other hand, if you live on stress an caffeine and have that skill set... You could make a lot of money.

    On the gripping hand... You would probably also make an ulcer.


  • Grade A Premium Asshole

    @accalia said:

    You would probably also make an ulcer.

    There ya go. Always pursue happiness, not pay.



  • I'm liking this thread topic, if only because it's helping to show me where the gaps in my own knowledge are.

    Being largely self-taught in C# and SQL, it sounds like I should brush up on my Python (which I've been meaning to do but putting off for months now anyway), and get into the habit of using Svn (which is another thing that's been on the agenda).



  • @blakeyrat said:

    It would be really interesting to teach ANSI C and C# 4.5 side-by-side. Write the same program in both and compare the code length/runtime/etc. Then ask the students which they prefer, and any that say ANSI C, flunk them immediately.

    Port C# to my STM32F051, then.

    @Groaner said:

    * Project Management in a Management and Communication Vacuum. You answer a support call from a client and find out they were sold $MASSIVE_FEATURE_XYZ, which does not yet exist, and they need it by tomorrow. It is your job to explain to them that the salesperson lied to them about the availability of said feature, but you can't make yourself, the company, or the salesperson look incompetent in the process*. Good luck.

    • Walking on Eggshells While Juggling Chainsaws. Sometimes, management will give you conflicting directives or no directives, and you won't hear anything unless you screwed up, in which case you'll get an earful. Naturally, there will be no documented policies, so there is never any safe course of action. Additionally, what is the right course of action today may be taboo next week, and nobody will tell you until after you screw up. What do you do?

    • Comebacks. Management assumes that developers are overpaid, whiny, prima donnas (even though their own developers are paid at least $30k below market), and thus their opinions about the codebase and product are invalid. Any complaints about an unmaintainable codebase and a broken schema that can't change without a year plus of refactoring will be countered as not being profit-generating work. How do you counter that counterargument?

    • Politics. If you work too hard, you might be seen as a threat and others may try to get you fired. Someone might also work less hard than you do but gain more clout and responsibility due to charisma/sleeping with the boss/etc. How can you make sure your voice gets heard?


    Unfortunately, no matter how hard you try to teach these things -- there will always be a way for a new generation of manglers to bypass everything you do. (If nothing else, there's always the "don't hire guys from XYZ school -- they're technical greats, but 'not team players'" or some other papering-over-the-baloney-sandwiches excuse for hiring cut-rate employees -- although there are folks out there who really are not team players, there are also plenty of manglers out there who use every excuse they can get to dispose of anything hinting at competence at the first opportunity.)

    @EvanED said:

    I was going to reply to this earlier, but didn't get around to it. Given your other languages, I don't like your choice of Clojure. Python already serves as a representative of the dynamically-typed languages, so Clojure is mostly getting you pure functional. But if you were to pick ML or Haskell instead, you not only pick up the pure functional category but also a language with strong type inference capabilities, which is otherwise lacking from your list. I feel like there's a decent chance more features from those languages will be "imported" to more traditional languages in the future (see the growing popularity of things like C++11's auto for a much weaker type inference feature being imported to many more C-like static languages) and I'd consider exposure to such a language to be pretty important; from the standpoint of a software engineering degree, I suspect that both O'Caml and Haskell are more popular than Clojure, though I've not seen data on that.

    You have a point there -- I only went with Clojure because it fills the role say, Scheme does in the language web while still having a sense of practicality in its head. If I were to go with a ML family language for this task, it would likely be F#, for the exact same reason -- while it comes from a language family that can provide scholarly value, at the same time, it is a member of a mature ecosystem that allows you to use it in a wide variety of real-world apps.



  • @trithne said:

    Being largely self-taught in C# and SQL, it sounds like I should brush up on my Python (which I've been meaning to do but putting off for months now anyway), and get into the habit of using Svn (which is another thing that's been on the agenda).

    Python is an excellent choice of language to learn -- it'll help you wrap your head around dynamic languages without instantly throwing a pile of 'wat' and :wtf: at you like JS or PHP will, and it will also give you the opportunity to extend your reach into Linux-land rather readily.

    I would suggest learning hg instead of svn, though -- DVCSes scale downwards better due to the lack of a server process, and also give you more flexibility to experiment with branching and merging.



  • Might as well start getting them ready for the real world, IT's version of the Kobayashi Maru: assign a project that you know would take an expert six months. Give them a four-month deadline. Three weeks before the due date, abruptly change 80% of the requirements.



  • @tarunik said:

    If I were to go with a ML family language for this task, it would likely be F#...
    I think I'd be fine with that, though I'd want to do some investigation first about how much it's used; I'd worry that even though it's got .Net behind it, it's sitting off in the corner even compared to O'Caml. But it might not be that way; I'm not in a particularly good vantage point to answer that kind of question.

    @tarunik said:

    Python is an excellent choice of language to learn

    I'll second this; a bit off-topic for this thread, but I think I've pretty much been sold on Python as the "best" language for most intro programming classes; I think it really spans the spectrum well from being pretty good pedagogically to being quite useful for real software.

    @tarunik said:

    @trithne said:
    get into the habit of using Svn

    I would suggest learning hg instead of svn
    I thought about suggesting hg or git, and decided to bite my tongue because I don't want to restart that discussion here. Just... be aware there are other choices and consider them. (I've written an intro document that tries to serve as a general intro to VCS applicable to both centralized and DVCS and for the most part attempts to be neutral; I wanted one for my class and couldn't really find what I wanted out there somehow. If you want a link, PM me.)



  • @tarunik said:

    I would suggest learning hg instead of svn, though

    What little tinkering I've done with VCS has been using BitBucket, and I don't recall offhand if I was using it in Git or Mercurial style. I think Mercurial, but I could be wrong, as it's all at home and I am not. It really just comes down to everything I've worked on has been a solo gig, and while VCS can be very good to have even solo (I kinda wish I'd been using it while doing some things that I've then had to roll back), I've never needed to. A poor excuse, but one nonetheless.



  • I occasionally think fuck, I deleted some code yesterday and I need very similar functionality today and then I remember that I use version control so I can just ask it for yesterday's changes.

    Also, I found out about git add -p yesterday.



  • @Polygeekery said:

    Yeah, the proper course of action when you encounter the need for those skills is to polish your resumé.

    But that's the easy way out! Incidentally, that's also what most people there did after a year or two.

    @tarunik said:

    team players

    I love this term. It means whatever the speaker wants it to mean.

    @tarunik said:

    Unfortunately, no matter how hard you try to teach these things -- there will always be a way for a new generation of manglers to bypass everything you do.

    The best counter to these techniques and the solution to the underlying problems is to hire someone with the experience of dealing with them. Ironically, this person will never get hired because 1) said person's salary requirements are twice the salary offered and 2) said person has been there before and knows better.



  • [apologies for continuing this derail]

    @ben_lubar said:

    Also, I found out about git add -p yesterday.

    Next you can discover git add -i :-)



  • git add --interactive feels like too many steps, too far from the command line, too far from the home row. I prefer using a combination of -p, plain add for conflicts, and auto-add from my IDE for new/deleted files.

    Contributing to this is that .gitignore is usually checked in.



  • I don't have to worry about conflicts since it's just me on this project. For me it's git status, git diff, and then either git add . or git add -p filename depending on how many changes I've made.



  • Gee. Thanks a lot for all the great suggestions. Some of them I have covered already; we have a tradition of project-based fail-to-learn real-life-problems courses at our univ., but have, IMHO, stagnated a bit when it comes to the technical infrastructure.

    I had not thought about the importance of exposing them to legacy code. It is sometimes done implicitly (like in the software architecture course where they get to reverse engineer the architecture decisions of an open-source system), but not as a deliberate thought (or learning outcome, as the current expression is)

    Some of the things are done on a per-teacher basis. For example, I require students in my classes to use a VCS and include me in the repo -- simply because I can then see who is contributing and can adjust their grades accordingly, and I am also meddling on the side (like five minutes/week) to set up a Jenkins server. My idea is that their workflow should be to:

    1. Clone my base repository, that includes instructions and basic unit tests
    2. Hook it up to my build server
    3. Extend with their own tests
    4. Implement the assignment/project
    5. (I am unsure about the next step, but my idea is that they) Once done, do a pull request to my base repo.
    6. I then double check that they have not meddled with my basic unit tests, perhaps add a few more, and run against the build server.
    7. Discuss and iterate
    8. Review project for all non-automatically testable stuff, and
    9. pass or fail them on the course. (never actually merging their pull-request with the base repo)

    First step: I have been advocating for several years now that rather than having the basic programming teachers tell the students that "If you keep your project files on your networked user account (J:) Visual Studio will be too slow to use, so copy your project to C:/TEMP, and don't forget to copy it back once you are done", I want all students to only get a VCS login and no user directory whatsoever. No Commit -> no Cookie + no Grade. Problem is, I hold the new student's ability to learn and to take responsible decisions in much higher esteem than do the Powers That Be.



  • @da_Doctah said:

    requirements

    Requirements? The FWP thread is over there ↩ ⤴ 🔄

    On the topic at hand, if you can make them work in teams and doing code reviews between them I think it could also improve the course without having to teach anything. They'll learn from each other and increase code quality so you don't rip your eyes out.

    Also, think about us and send some side bar content our way.


  • kills Dumbledore

    @ben_lubar said:

    git add -p

    Interactively choose hunks of patch between the index and the work tree and add them to the index

    Hunk of patch sounds like something from Cosmo



  • @Eldelshell said:

    On the topic at hand, if you can make them work in teams and doing code reviews between them I think it could also improve the course without having to teach anything. They'll learn from each other and increase code quality so you don't rip your eyes out.

    We've tried that in some types of courses. Sadly, it usually turns into a case of GIGO. If the reviewers do not understand anything they will, to use a dutch expression, miereneuk on all the small stuff ("should you really indent three spaces here?") and miss/ignore the important bits. Once the smart students see this -- regardless of whether they get away with it or not -- they will adjust their level of committment accordingly. And then it is just as much work to review the reviews as it would be to review the original code.



  • @Eldelshell said:

    Also, think about us and send some side bar content our way.

    And just how are you going to continue working once you've scratched your eyballs out?



  • We're a bunch of masochist around here.


  • ♿ (Parody)

    @EvanED said:

    I thought about suggesting hg or git, and decided to bite my tongue because I don't want to restart that discussion here. Just... be aware there are other choices and consider them.

    I like hg for this application, because in a way it sits in between svn and git. The commands are very svn-like. Using it locally, you practically have the same workflow. However, once you have remote repos involved, you can start grokking the nice things about DVCS.

    The downside to svn is that you have to have a server, even if it's only local. That's not the end of the world, but not necessarily someone needs to futz with to get going and get comfortable with SCM.


  • ♿ (Parody)

    @trithne said:

    VCS can be very good to have even solo (I kinda wish I'd been using it while doing some things that I've then had to roll back), I've never needed to.

    The advantage (as I mentioned already) of something like git or hg is that it's super easy to make your working directory a repository. No server or anything outside of your directory required.


Log in to reply