The challenges of teaching software engineering - <AUTHOR> https://www.sicpers.info/2019/07/the-challenges-of-teaching-software-engineering/ <comment><USER2> You seem to be starting too abstract. Analogs help and so does starting from a point where the students can experiment and get feedback on their mistakes from their own code, not from abstract concepts. These are lessons I learned when we designed and taught a 8 week coding course for Graduate students who had never touched code before. Feedback for us as teachers was instant. (Analogs. Analogs. Analogs.) Imagine learning about structural engineering - would you rather start by prototyping bridges with different materials and seeing how different structural designs hold up better, or would you prefer to be lectured about conflicting philosophies on proper road arrangement, materials and tensile strength first.

Analog example I used (explain like they're five): Front end, backend, middleware, databases are like a Macy's animated window display. HTML is choice and order of the mannequins in the window. CSS are the colors and positioning. Javascript is the string that makes visible characters move. Middleware (Python, Go, Java) are the sales clerks grabbing goods from the warehouse (database), serving customers, and updating the window panes.

The course did a lecture on HTML/CSS first day, Javascript second, dug in deeper by debugging a snakes game in JS, Git on day 3 (failed for same reasons you mentioned), Ruby on Rails (immediate productivity was key), Wordpress installation, then PHP deeper dive, etc. One student said "I can't believe I paid someone $20k to build me a Wordpress site that I can now set up and customize myself after a few days."

Always start with immediate productivity for non CS students - let them sink teeth into the ideal outcome, then modify that ideal, then learn how to break and fix it, then dig deeper into why and how things work before going to best practices. If they don't know why something broke, they can always go back to figure out how it should work first.

<comment><USER2> If I was to do it again, I would teach Git with paper - have the class augment a paper tree with paper nodes or something else tangible. You can even have them write a collective story instead of code. The more abstract the topic, the simpler the analogs to get the largest subset of users to grasp it.

<comment><USER3> I have to strongly disagree with this approach to teaching git. I've been in software engineering for a decade now and have taught many entry level and experienced devs about git. If you start out with trees and other git internal concepts you're just going to lose them. Have them create a directory, put some files in it, `git init`, add all their files and commit. Have them make some changes, add and commit again. Then ask them how their fellow devs would see their changes. This leads into the distributed nature of git and pushing to remote repos. Continue from there with more practical work and repeat. I've seen it take devs months of working with git daily to start to understand some of the more advanced concepts so it needs to be practical up front.

<comment><USER4> If you've seen devs take months of working with git daily to start to understand some of the more advanced concepts, then maybe the problem is the current teaching method. They might learn the more advanced concepts a lot faster if they learn the concepts first.

<comment><USER5> You're assuming they want to learn. I've seen devs work with svn for years which is conceptually much simpler and they still don't know how branching and merging work, they'll do things like checkout each branch separately and copy files over rather than merge.

Edit - also a favourite interview question for anyone that claims to be familiar with svn is "what does the switch command do", a quick and easy filter to seperate those that know from those that claim to know.

<comment><USER6> I felt their attitude towards SVN was silly, so I decided I would make my change the right way. But when I went to merge, I got a bizzare error about a 'missing revprop' and it knocked the wind out of my sails.

I'm ashamed to admit it, but I ended up copying the files just like everyone else on that project for the brief stint I worked on it. :(

</comment></comment></comment></comment></comment></comment><comment><USER7> No offense to the OP but the syllabus is ludicrous. This isn't teaching anything. It's so packed with random software technologies, they will leave the course with nothing. Cut down on the syllabus and focus on a few topics. Make it project based so that you're building on the same project over the 4 days and learning more about programming.

Split the other stuff like git, databases, OOP, functional programming, machine learning my God, for another course. There is no way anyone taking this course will get anything from this, it will just be a confusing mess of information that is quickly forgotten.

<comment><USER8> I read it assuming it was a semester long.

Then I saw it was four days.

</comment></comment><comment><USER9> I'm sort of curious how one could "learn" software engineering in a week. Judging from the article, it seems the course assumed very little prior knowledge about SWE (teaching OOP at the beginning). Wouldn't it make more sense to teach a course assuming some basic background knowledge (like OOP and command line utilities) and use the teaching time to discuss architectural patterns, testing practices, etc?

<comment><USER10> Biggest thing that needs to be taught as one of the fundamentals for software engineering is approaching problems with scientific method.

Design, testing, and debugging (which takes up more resources than writing code) require skill in forming good hypothesis and methodical way to test that hypothesis.

These type of courses should be designed more towards those skill sets than just learning to write code.

<comment><USER11> I've actually been thinking at work recently that our work is very much in line with making and testing hypothesis. When we add code or edit existing code, we hypothesize that the program behavior will change in specific ways, and then we test those hypothesis via various means of manual and automated testing.

I would actually add to the above though that I think it's important people learn to approach problem-solving from a mathematical perspective. Unfortunately, a lot of people that get into software engineering don't like math, and they would generally be averse to learning about software engineering this way, but I think a lot of bad code gets written because the person writing it didn't approach the problem with the right structure or rigor.

<comment><USER12> Where you say "mathematical" I'd suggest "logical". Also, formal logic (Aristotelian, sentential, predicate...) is distinct from mathematics per se. Agreed that fundamental problem-solving skills are in too-short supply.

</comment></comment></comment></comment><comment><USER13> I don't know exactly what the goal of the course is, or where he's teaching, but...

it seems like a really hard problem.

Making working computer systems---like a drawing program, or an Amazon deploy ---can be really hard, or really simple. You can teach someone enough Python for fizzbuzz in twenty minutes. Teaching them enough... _everything_...to get a web version of fizzbuzz, that checks a database for the words (it might be "nargle" and "gargle" by user preference, after all), with a Python install that they manage, a postgres install that they manage, that they don't feel at a complete loss about if something goes wrong, and to collaborate with others on this...is another matter entirely.

I'm not one of those who believes programming ability is innate, but there are absolutely compounding effects that can certainly have basically the same effect. In retrospect, I thank my lucky stars for my 6th-grade computers class using HyperCard.

</comment><comment><USER14> I taught a 2-hour session to a group of middle schoolers and high schoolers back in December - obviously, not as big a deal as the author, but still something I'm proud of - and ran in to the same issues. These were all students who either had done some programming or were interested in it. I started with "ok, so, first, go to your command line..." and it went sideways from there.

One thing that the students taught me that helps overcome some of these things is a site called [https://repl.it/](https://repl.it/) . I stopped my plan, started using it, and taught the rest of the class using repl instead in order to focus on the concept I was trying to teach. Obviously, as a professional software engineer you need to know about git, command line, etc., but those aren't what software engineering is. They _rarely_ excite new comers to the field. Using repl.it helped to get to the core ideas faster for people who don't really know as much.

<comment><USER15> If you enjoy repl.it, you might enjoy StackBlitz as well. I've had fun using StackBlitz to put together some prototypes of React apps.

I love repl.it too, of course! It's nice to have several great tools to choose from.

<comment><USER14> Interesting, thanks for the reference!

</comment></comment></comment><comment><USER16> What is software engineering anyway? I've heard this term for almost 40 years, and still wonder what it really means since everyone has a different idea.

<comment><USER17> Dr. Margaret Hamilton coined the term while developing the software for Apollo 11. She went on to design a system that permitted bug-free software development ("Higher Order Software" or HOS) and attempted to market it. It was panned by e.g. the Navy and Dijkstra, and languishes in obscurity to this day.

The basic details of the system are described in a book called "System design from provably correct constructs: the beginnings of true software engineering" by James Martin (he mentions Hamilton in the references.)

In modern terms you work directly with an AST and the UI only permits modifications by operations that preserve the correctness of the AST. It eliminates all sources of bugs, and it was simple enough to teach normal people to use it with just some coaching.

Anyhow, _that 's_ "software engineering". The rest of us are just pushing text around in buffers and _hoping_ it isn't broken. There are a few people using math to make software, and it works out really well (E.g. [https://www.categoricaldata.net/](https://www.categoricaldata.net/)), but mostly "software engineering" as it is usually used is an oxymoron.

<comment><USER18> > you work directly with an AST and the UI only permits modifications by > operations that preserve the correctness of the AST. It eliminates all > sources of bugs

With the caveat up front that I know nothing about this beyond what you have written: wouldn't this just catch compilation bugs? The compiler tells me if the blob of text I gave it is incorrect in terms of any syntax errors. Business logic bugs and accounting for bogus data seem more important to me.

<comment><USER17> Yes, you and skybrian have got the idea. It wasn't magic, it just prevented entire categories of preventable bugs, syntax and semantics.

You could still use it to write correct programs that did the wrong thing. In other words, it couldn't catch bugs that occur "between the keyboard and the chair".

FWIW the tech has a bit of a Wikipedia page now: [https://en.wikipedia.org/wiki/Universal_Systems_Language](https://en.wikipedia.org/wiki/Universal_Systems_Language) but it doesn't seem very informative to me. YMMV

<comment><USER18> I can imagine this being useful for people new to programming. I've seen plenty of times where students get overwhelmed with all of the different keywords/syntax they just learned and don't know where to apply it. Being able to give a list of possible actions available from the current node(?) could be a huge help.

<comment><USER17> Apparently they sat down, like, accountants in front of this thing and they could derive trees (programs) that automated tasks just fine with a bit of coaching. _shrug_

(But that also worked with Lisp+Emacs!

> programming new editing commands was so convenient that even the secretaries > in his office started learning how to use it. They used a manual someone had > written which showed how to extend Emacs, but didn't say it was a > programming. So the secretaries, who believed they couldn't do programming, > weren't scared off. They read the manual, discovered they could do useful > things and they learned to program.

[https://www.gnu.org/gnu/rms-lisp.html](https://www.gnu.org/gnu/rms-lisp.html) )

</comment></comment></comment></comment></comment></comment><comment><USER19> When I was doing my Ph. D., I also ended up teaching some software engineering related courses. One thing that struck me and that I've since fixed by becoming a software engineer was the notion that here I was teaching Software Engineering without any experience whatsoever actually engineering any software professionally. This is the big problem in academic education on this topic: the teachers typically have little or no relevant experience actually engineering software because they have been in university all their life and as such lack experience working for extended periods of time with an actual team on some actual non trivial software. Lets just say that I learned a lot about this stuff after I left the academic world.

A good practical introduction to software engineering should cover a lot of ground and most of it is going to be non technical. Learning how to program is mostly out of scope for a software engineering introduction. Assume the students have already learned some programming language and have some experience building small programs and maybe have already had some algorithm courses, etc. It doesn't really matter what language or tools they use. For the purpose of an introduction, pick something simple where the focus is mostly not going to be fighting with the tools.

The key thing to learn as a software engineer is working with multiple people and the project dynamics that are associated with that. So:

\- project management and different roles in software projects, different ways of structuring teams, etc.

\- overview of different process methodologies common in the industry and where they came from: scrum, kanban, watefall (don't do this), etc.

\- different types of testing and their importance for continuous integration and deployment

\- different strategies for estimating cost, complexity, duration, etc. and their flaws and pitfalls.

</comment><comment><USER20> Most of the problems he is having seem orthogonal to software engineering, which he is trying to teach. It's clear he's teaching it as an intro course. In my opinion, SW engineering absolutely should be taught as a later course - after the student has had quite a bit of exposure to programming.

I wouldn't expect a SW engineering course to require _teaching_ much command line usage. That's a thing for lower level courses. Same with editors.

Don't use git if it is confusing to students. Mercurial is as good and much friendlier. The potential benefits to git are fairly advanced and will not have any impact at an introductory level. Your goal is to teach the concept of revision control, not the internals of git (which every git advocate says one should know if one wants to use git well - just search any HN thread that comes up about git).

As for Python vs Python3: Again, I would not expect a SW engineering course to teach any language. The course should let the student pick a language of his/her choice.

</comment><comment><USER21> I think there's a hype in quickly training software engineers. This article is an example. We poke around with tools to find quick and easy ways to create software. Tools have been improving quickly but creating software remains challenging. The tool race is influenced by market more than software engineering.

The discipline of software engineering has not changed much for decades. To teach effective software engineering, we need to start with the principles. Some fundamental questions:

\- How do we create functional and scalable software?

\- Given an existing (complex) software system, how do we maintain and incrementally improve?

One important principle I learned outside of school and training: software is never just code, we always need to think about the user ecosystem around the software. Failure to understand this principle leads to wasteful effort. For example, attempt to rewrite of the code.

These principles are very abstract. We cannot teach them easily. People use tools and new technology to cover up their lack of understanding.

</comment><comment><USER22> > git, in particular, is decidedly unfriendly. What I want to do is commit my > changes. What I have to do is stage my changes, then commit my staged > changes. As a result, teaching git use takes a significant chunk of the > available time, and still leaves confusion.

In college, the way my professors got around this and other things like it was by creating an alias file and scaffolding code. We would get a project that was 1/2 done with all they annoying crap, and then only have to implement the algorithms. Then we would save our work with a single simple command with no options, that was just a shell script for all the source control steps (rcs at the time, but the idea is the same).

They never actually taught us about source control. We just learned it on our own when we stopped having access to their aliases. But at that point we had enough knowledge that we could figure out it (or we were in our first job and the senior devs taught it to us).

</comment><comment><USER23> If it's an introduction to software engineering then I think leaving out software craftsmanship or functional programming, etc is not necessarily a sin.

And git (the cli not the versioning approach per se) never made sense to begin with. It is extremely user hostile. So no surprises there.

<comment><USER24> I have heard often people's view that git is not user friendly, but it's always confused me because that hasn't been my experience compared to any other tool I need to learn. Can anyone explain more this view? Perhaps I'm too accepting and forgiving.

<comment><USER23> `git merge`, `git rebase`, `git rebase -i`, `git revert`, `git checkout`, `git reset`, `git reset --hard`, `git log`, `git reflog`, `git stash`, `git cherry- pick`, `git add`, `git rm`, `git status`, `git commit`, `git push` and squash, reword, fixup, pick and f@ck knows what else. Who wants to really use all this bullshit just to do versioning?

Especially if you are a beginner, this doesn't make any sense (and not even later in many cases)

In my experience during the last two decades or so in the industry, there is always a special kind of person in the IT field who takes pride knowing all the nitty-gritty details of the latest shiny versioning tool. Should it be IBM Clearcase or SVN or CVS or Git or Mercurial. Even though that most of these softwares only slightly improve the user experience and only claim to solve the users' problems, so they over promise and under deliver. But there is this special kind of person who takes pride in it.

To me this seems like someone who takes pride in knowing all the details of his toaster. Might be impressive, but also completely irrelevant for the 90% of the toaster users.

<comment><USER25> > Who wants to really use all this bullshit just to do versioning?

Nobody. It is a strawman or should be.

You can teach _everything a beginner need to know_ about git _as an ordinary team member_ in less than one A4 page and less than half a days work.

Of course this means part of what you teach then is when to talk to the git expert on the team but as long as beginners _stay away from_ squash, rebase etc they should be fine.

Ok, add another half day about effective diffing and merging too, it is a big topic and useful outside the context of git too (local history etc).

<comment><USER20> >Of course this means part of what you teach then is when to talk to the git expert on the team but as long as beginners stay away from squash, rebase etc they should be fine.

The thing is, if you ask 10 git experts what should be taught to a beginner, you'll get 10 different A4 size pages. As an example, when my team (finally) switched to git, the expert on the team made a tutorial on what commands to use, and what to avoid/ignore. Looking at it now, he taught that rebase is almost mandatory and gives problems you're guaranteed to run into if you don't use rebase.

Not saying I agree with him, but that is one problem with git - no clear consensus on beginner friendly features.

</comment></comment></comment></comment></comment><comment><USER26> > git, in particular, is decidedly unfriendly.

Why do people _persist_ in pushing one of the most user unfriendly tools to ever exist?

</comment><comment><USER27> It's very difficult to teach software engineering because you need a big project to create and/or modify.

Another reason it's difficult to teach is because of a complete lack of a legitimate discipline to teach.

</comment><comment><USER28> Having taught software, devops, and the like for years at this point, while this article touches on some difficult parts of teaching, they're all just side effects of bigger difficulties of teaching software.

a) Everything is the "tip of the iceberg" \- which makes teaching what you actually want to teach tricky. Which is why so many resources do the whole "we won't go into it, because this is a large topic." For example, Linux. Most projects and resources require this, but barely any actually go in-depth.

b) Everything is always changing - and so you have to either support your students in the face of these changes or constantly keep the materials up-to- date. This is one of the largest challenges, if not the largest challenge.

c) Everything has to be engaging - it's not enough to know what you're talking about. You have to know how to talk about it in a way that creates engagement and thus learning. This isn't something you learn how to do when slinging code left and right.

d) Everything needs to be TAUGHT, not said - the ability to teach is often an after thought for folks looking to educate. If you want to really help your students, you have to learn how to teach so that they can think independently. Not rely on cheatsheets, prep tests, and step-by-steps.

e) Every student needs the motivation to learn - usually instructors' will stop at spitting out their knowledge. The best instructors help their students push through their barriers, whether personal or professional, and get the learning done. It's easy to learn in a structured school system. It's hard to learn when you have multiple kids, a full time job, and all the emotional baggage of being an adult.

Now, to be clear, I'm talking about teaching modern, practical implementations of software...not CS theory or other things that are far more evergreen and less technical.

</comment><comment><USER29> I was a teaching assistant for the Introduction to Programming course on the first year of a CS degree. At the very least I can say it was a humbling experience.

One thing I learned while teaching complete novices is that it is really hard for experienced engineers to get into the mindset of students. You need to forget everything you know and start more basic that you think it's necessary. You will need to teach people what are variables, list, functions, and so on.

As an example an student got confused when we wrote something like the following:

let X = 1; let X = X + 1;

How could X be X + 1 at the same time? Maths don't work that way!. It might seem absurd to a programmer, but if you are in the mindset of someone who is only familiar with maths equations, it makes sense.

So yeah, I would forget git, command line, tangents and whatnot, and focus on very basic concepts instead.

</comment><comment><USER30> This is the course he is talking about: [https://github.com/OxfordRSE/rsd- engineeringcourse](https://github.com/OxfordRSE/rsd-engineeringcourse)

So to become a "real software engineer" and not "just a programmer" one needs to know how to create requirements, use source control, do modular, and/or object-oriented and/or functional design, deploy your software, and take advantage of open source?

Those are things that all programmers need to know (assuming "programmer" means someone whose primary job is programming). Which is why the distinction between "programmer" or "developer" and "software engineer" is bogus. Its usually just an attempt to justify higher or lower compensation.

</comment><comment><USER31> The secret of programming, and it's greatest challenge, is that the ability to get "good" at it is largely innate. Just like you can't teach people to prove math theorems (the ones that one encounters in an elementary college proof class), you can't teach great software engineering. Near anyone can learn to build a javascript app, beyond that, to higher levels of abstraction and complexity, things become murky. It's why large tech companies ignore past experience, it proves nothing. They need to see you use abstractions from memory on the spot to ensure you have the capability. It's not perfect, but nothing is.

</comment><comment><USER32> Software engineering at least has a fundamental underlying educational system supporting it (comp sci, EE).

I think the harder thing is training sysadmins, there's no real formal education. I know we're downplaying a lot of the traditional sysadmin roles and pushing for more development in sysadmin but the sysadmin approach is still required, and the only thing that keeps it going is the corpus of industry knowledge, a myriad of vocational or vendor based certs and a willingness to teach.

Or am I wrong?

</comment><comment><USER33> I'd love it if there was some sort of "helper terminal" that could teach people things like git, and basic command line stuff as they went.

It could catch common errors and provide useful explanations. It could possibly even go as far as attempting to understand plain text commands, eg "delete the file file.txt" and suggest commands to do that.

<comment><USER25> Clippy, as orginally designed before they gimped it? ;-)

Or just contextual help as it existed in many Windows applications (and certain current iOS apps).

</comment></comment><comment><USER34> Sounds more like "the challenge of using a mish-mash of non-integrated tools with no interface". Developers could definitively solve this by moving away from 70+ year old abstractions (files, terminal) towards things more in line with Smalltalk ideas. But I guess it's better to make thousands of beginners suffer each year, instead of admitting that the current way of doing things is conceptually flawed and outdated.

[https://www.youtube.com/watch?v=I9LZ6TnSP40](https://www.youtube.com/watch?v=I9LZ6TnSP40)

[https://alumni.media.mit.edu/~mt/thesis/mt-thesis- Contents.h...](https://alumni.media.mit.edu/~mt/thesis/mt-thesis- Contents.html)

[https://www.youtube.com/watch?v=QTJRwKOFddc](https://www.youtube.com/watch?v=QTJRwKOFddc)

[https://github.com/pharo-open-documentation/awesome-pharo- ml](https://github.com/pharo-open-documentation/awesome-pharo-ml)

(And no, there is nothing special about copy-pasting commands and Unix pipelines that cannot be easily recreated in UI if the UI is designed to be programmable. )

</comment><comment><USER35> I hope they don't add Jupyter notebooks to the syllabus. One day we'll wonder what went bad and whole programs are written in a single module/file :)

Jokes aside, Jupyter and relevant projects are great tools but they drive programmers towards wrong paths.

</comment><comment><USER36> > \- you need to either tell people how to set their core.editor, or how to > quit vim.

You'll pry vim from my cold dead fingers.</comment>


Is College Obsolete? - <AUTHOR> http://www.sixmonthmba.com/2009/04/is-college-obsolete.html <comment><USER2> Is it just me, or does a "college is obsolete/failing/just plain sucks" article hit HN about once every week or two? And most tend to assume the target industry will be IT or web-based, ignoring fields like engineering or non-computer science where it's much more difficult to do online-only learning.

This instance of the college rant does make one interesting point about online interconnectedness as a useful way to bypass credentials. References and personal connections are certainly becoming more important as connectedness is easier to achieve online, and small professional communities become more tight-knit. I'm not sure how much effect this will have on credentials, but I do think it will dilute the networking advantage of highly ranked schools.

<comment><USER3> I've noticed this too. Along with the everlasting nature/nurture debates. I think there are two reasons why people on HN (myself included) like pulling higher education into question.

1\. People in CS realize that the field is changing rapidly and that their 50 year old professors are somewhat losing touch. This contributes to the feeling that one could just as well work and autodidact.

2\. People in CS are notoriously bullshit averse and realize that higher education is riddled with social prestige and research projects that are of little value but sound sophisticated.

I would be interested in what others think of these two points. Thanks.

<comment><USER2> I can see some merit in those points, but mostly only because computer science as an academic field and the jobs real-world CS majors do are fairly disconnected at the moment. Most of the "50 year old professors" I've met are nowhere near losing touch with the bedrocks of "computer science": information theory, computation and algorithms, etc. But they probably don't know much about the rapidly-changing landscape of Internet technology, and there are good arguments in either direction whether they should.

I know people who've gone the autodidact route in CS and they do just fine, but I do notice it leads to a particular kind of snobbery _against_ higher education because they learned everything online, so why can't everyone? Trouble is, a fairly high fraction of human activities don't lend themselves to that kind of learning. And some of them, like green energy technologies, are even the kinds of things some startups want to get involved in. Higher ed becomes pretty damn necessary in these cases.

</comment></comment></comment><comment><USER4> "71% of college graduates are unable to read proficiently"

huh? according to the link they cite: <http://nces.ed.gov/NAAL/kf_dem_edu.asp> looks like college graduates are amongst the best.

<comment><USER5> He also changed the link (while I was writing a comment). It now points to the general NAAL site, instead of that graph, so that you'd have to dig through a wad of information before discovering the link doesn't back up his claim. Bunk.

</comment></comment><comment><USER6> This, coming from a blog titled Six Month MBA...

</comment><comment><USER7> The fact that people use colleges as a source of credentialism doesn't actually change the structure of classes themselves. So, to claim that colleges are obsolete because of the futility of using the knowledge of which one a person graduated from as a shortcut for actually assessing their value to your enterprise isn't effective...well, that just doesn't make follow. Maybe credentialism is practiced too much, but surely there is more to college than that. A well structured school will ensure that you learn something in the process of achieving that credential.

</comment><comment><USER8> Not sure, but this meme has certainly entered senescence.

</comment><comment><USER9> Is a college degree an absolute indicator for expertise? Of course not. But a college degree is hardly going to be made obsolete by the internet. Networking has always been an important part of getting a job, perhaps more important than any other one factor. The internet can certainly help networking. But I don't believe you can equate networking on the internet with having a degree. The degree points out particular things about you to the potential employer (that you can stick with and complete a degree program, for instance) and I don't think that necessarily equates to "someone vouching for you"

</comment><comment><USER10> Summarizing quote: "And they haven't just failed abstractly or in general. They've failed me personally."

Interesting logic.

</comment><comment><USER11> I can't believe a user with over five thousand karma submitted this. What the hell. Flag this garbage.

</comment><comment><USER12> so now we've had the end of college, twitter, google, the free world, MBAs, etc. etc. etc.

the blogosphere seems to be on an existential kick of late.

must be the bad economy.

</comment><comment><USER13> College is amust! Dixi.

</comment><comment><USER14> no

<comment><USER15> yes

[edit: just to win the inevitable continuation of this argument, yes infinity + 1!!!]

<comment><USER16> I voted this up because it's no more useless than the comment it's responding to which isn't getting voted down.</comment></comment></comment>


Synthesising Drum Sounds with the Web Audio API - <AUTHOR> https://dev.opera.com/articles/drum-sounds-webaudio/

<comment><USER2> A page with an actual play button, [https://chrislo.github.io/drum_synthesis/](https://chrislo.github.io/drum_synthesis/)

How can an article detailing the synthesis of drum sounds using web audio apis and not have a play button?

<comment><USER3> I started reading the article and creating the kick drum in my console, then skipped right to the playback on this page and was initially very excited by that hihat sound. It was a bit of a let down, although not much of a surprise, to find out the hihat was a sample.

Having made a JS/CSS drum machine (sample playback) emulator a few years ago @ [http://bitrotten.com/dr110/](http://bitrotten.com/dr110/) and more recently spending time doing emulative sound design on a modern drum machine @ [http://bitrotten.com/tempest/](http://bitrotten.com/tempest/) I'm still enthused by this demo and write-up. Next month I return to an hour-long commute by train, and now I've got a pretty good idea of how I'll be spending that time.

<comment><USER4> Glad you enjoyed it! Synthesizing cymbals is hard, but not impossible. I admit, I did "cheat" a little here, but at least it gave me a chance to talk about sampling. If you're interested in cymbal synthesis, this article is great: [http://www.soundonsound.com/sos/Jun02/articles/synthsecrets0...](http://www.soundonsound.com/sos/Jun02/articles/synthsecrets0602.asp).

Should keep you busy on your commute!

</comment></comment></comment><comment><USER5> They said that removing high frequencies makes a snare drum better which may be true, but then they used a highpass filter.

</comment><comment><USER6> Very interesting article.</comment>


Tell HN: New Discord phishing attempt going around - <AUTHOR> A clever phishing attempt seems to have emerged, where you get a direct message from someone on your friends list, and it contains a URL that looks like a Discord URL. The link takes you to a login page that looks identical to Discord's own login page. You can guess the rest.<p>Details here: https://twitter.com/splitsplatted/status/1143556723266994176 <comment><USER2> The mitigation recommendations in that thread seem a bit weird, effectively telling people to completely abandon compromised accounts.

Does discord have some weird architectural aspect that doesn't allow for a regular a) change password, b) enable 2FA, c) logout all existing sessions mitigation to leaked credentials?

</comment><comment><USER3> theres nothing fancy about it. its just a plain ol' copy login page and start phishing with similar looking domain

and the twitter guy makes it sound like its a huge deal...</comment>


[Microsoft] NeuronBlocks – Building Your NLP DNN Models Like Playing Lego - <AUTHOR> https://github.com/Microsoft/NeuronBlocks <comment><AUTHOR> NeuronBlocks is a NLP deep learning modeling toolkit that helps engineers/researchers to build end-to-end pipelines for neural network model training for NLP tasks. The main goal of this toolkit is to minimize developing cost for NLP deep neural network model building, including both training and inference stages. For more details, please check our paper: NeuronBlocks -- Building Your NLP DNN Models Like Playing Lego at [https://arxiv.org/abs/1904.09535](https://arxiv.org/abs/1904.09535). NeuronBlocks consists of two major components: Block Zoo and Model Zoo. In Block Zoo, we provide commonly used neural network components as building blocks for model architecture design. In Model Zoo, we provide a suite of NLP models for common NLP tasks, in the form of JSON configuration files.

NLP Tasks Supported Sentence Classification Sentiment Analysis Question Answering Matching Textual Entailment Slot tagging Machine Reading Comprehension Knowledge Distillation for Model Compression More on-going</comment>


Why Startups Should Prioritize Customer Service - <AUTHOR> http://www.forbes.com/sites/kylewong/2013/09/16/why-startups-should-prioritize-customer-service/

<comment><USER2> Usually when I see the same topics make it to the front page again and again, I get somewhat annoyed. But when articles that highlight the importance of customer service make it, I am genuinely happy to see it. Why? Well quite frankly, it is an area that still needs work and given how many aspiring tech founders are on HN, it is an excellent place to reiterate such a point.

Personal anecdote if you care to read: My roommate and I launched a mobile app a little over a year ago on our campus and it didn't do as well as we wanted. Sure, the app wasn't as refined as it could have been but we still expected far more users. Looking back, one thing we never did was reach out to our initial users and ask for feedback. This time around, just last week, we launched the same service but in the form of a website (alwaysbuzzn.com) and have reached out to almost every one of our initial users to ask for their genuine feedback. Not only has it helped us iterate, but it has shown our users that we care about what they think and the word is spreading faster than ever. Sure, we can say the website is more effective than the app, but I still point our success to our attention to maximizing the user experience beyond anything else.

</comment><comment><USER3> Nothing makes me feel better than hearing we have great customer service. You owe your clients great service. They're learning to use a new service that's constantly changing (sometimes for the worse) and dealing with your screw ups often. There are only so many times you can screw up with a client, but you can double that if you have great customer service.

</comment><comment><USER4> The Zappos methodology is the best I've heard so far:

Every new hire spends at least 2 weeks answering phone calls. That's how they get everybody in the company to actually care about their customers.

</comment><comment><USER5> Even big companies like Facebook, Google often have annoying, slow and unhelpful customer service.</comment>