I'm struggling to get them to accept basic software engineering things. I don't know how properly to stress to them that documentation, a good architecture, etc. is important.

We're about as structured as you can expect from four undergrads who are just farting around with machine learning, hacking ways around to figure stuff out. Everybody else views documentation, unit testing, source control, etc. as fluff, nice to have, non-productive, etc.

And like, I don't blame them; I can understand why it feels like a hurdle I'm trying to place on them. I'm doing what I can to help them see the light, but for now, ramble rant grrr argh

Comments

You must log in or register to comment.

devtesla wrote on February 17, 2018 at 2:09 AM

Ahh that's a pain. Like when something goes wrong you can fix things so much quicker if you do things the right way!

twovests OP wrote on February 17, 2018 at 3:16 AM

the first time TDD helped me solve a problem, my life changed and i wanted to form a cult. i wish i could share that experience.

musou wrote on February 17, 2018 at 2:59 AM

fight the good fight IMO. my school mostly graded on correctness and program structure only. i was really undisciplined in school about things like revision control, code style, good comments. as soon as i got my first programming job i was struggling to keep up in those areas. getting them to color inside the lines now will be a benefit to them in the long run even if they hate it now as much as i did then.

twovests OP wrote on February 17, 2018 at 3:21 AM

So the thing with this, the deliverable is only being graded on it's existence.

A corporate sponsor comes in with a project (a Real World Thing), works with students who write the code, and provides resources.

Maybe I should try getting them closer in the loop on our code? They've been trying to steer us towards good software engineering (e.g. weekly pointers like "hey go research devops and tell us about it!") but it hasn't been working.

musou wrote on February 17, 2018 at 4:03 AM

that's an especially good idea for anything that will be put to real world use

hollyhoppet wrote on February 17, 2018 at 6:05 AM (edited on February 17, 2018 at 6:06 AM)

i don't have any valuable input but just wanted to say you're braver than i was in school trying to do anything but Just Survive bad group members lol

Moonside wrote on February 17, 2018 at 8:14 AM

I spent more time tutoring my Very Bad project pair than coding my own parts, she regrettably had some major fear of programming despite being on the course.

twovests OP wrote on February 17, 2018 at 5:59 PM

Ahhh that's a Bad Time; what was the fear of programming like for her? Anxiety when starting projects?

Moonside wrote on February 17, 2018 at 11:26 PM

Now I can finally put my Undertale knowledge into use: she was a lot like Alphys good ending run (except Alphys was actually supercompetent in-story unlike the present person I'm talking about). Some problems:

Stops communicating when she had problems
the general lack of guts to just try out things
All or nothing thinking when it came to implementation. I think that coders mostly implement one thing at a time, see if it works/compiles/passes the test and move on to the next thing and learn from the experience and apply it to further cases. This was totally absent. I think she tried to figure it out all in her head and if she felt any uncertainty, she just didn't try to code.
Didn't habitually compile/test/see whether software worked and fix problems or annotate them if unfixed.
Couldn't read official documentation Java had.

Honestly I'd say it was mostly a series of emotional issues more than anything else. You can't learn coding if you fear compiler/test feedback and trying out things and fall apart when things don't work.

Moonside wrote on February 17, 2018 at 2:27 AM

Could you convince them that writing documentation is a nice way to procrastinate and makes the implementation part easier? I swear I solved an implementation problem (which caused no small amount of headscratching) recently just by carefully specifying the function to be implemented. By doing that I ended up describing the cases correctly which then made the implementation trivial. It was a recursive function so a botched case analysis easily leads to incomprehensible behavior.

source control, etc. as fluff, nice to have, non-productive, etc.

¡Dios mío! I'm glad that I've used source control for very low importance projects so that I can use it without any real effort when it's needed.

The crappy part of programming really is that there are so many useful tools that you have to bring together and tinker with to make them good. Like to write good unit tests you presumably ought to be specifying your functionality in good enough detail, your testing framework presumably has a few knobs to be set, then you have to make testing and documentation work with your build system, for Git you need a .gitignore file and so on, all this upfront work and busy work that makes it all easy to skirt.

twovests OP wrote on February 17, 2018 at 3:30 AM

We're doing a lot of machine learning stuff. I think it's a lot easier for them to write code, play around, and experiment (fluidly) without doing the unfamiliar rigidity of software engineering.

You're spot on with the crappy part of programming. We're using Python, so we have so much less busy-work than other languages.

Maybe I could convince them that growing their software engineering skills will result in a better end-result for them (in terms of professional skill development) and for our sponsor (in terms of a maintainable deliverable), rather than a poorly-documented but fully-functional prototype.