from Hacker News

Ask HN: Elitist or reasonable concerns on state of front end development?

by hashtree on 4/30/15, 7:15 PM with 10 comments

My freelancing to date has largely consisted of ML, stream processing, data integrations, microservices, and other backend work. However, more recently I've shifted to include frontend work with react/reflux/react-native/electron and I have run into a high number of issues with development practices. I find myself declining most work for obvious lapses in development practices and, on occasion, "duped" into accepting a client that sounds good on paper but isn't.

I have observed a severe lacking in areas like:

  - Testing (i.e. usually none, which is often spun like an odd pro that they are so "fast")
  - Devops (e.g. lack of repeatable/automatic deployments, things must be hand-touched, no continuous integration)
  - Project management (e.g. no tracking of bugs, features, etc via issues, no milestone usage, no documentation)
  - Git/Github basics (e.g. don't break the branch when doing PRs, create useful commit messages)
  - Understanding of CSS/HTML basics (e.g. best practices, standards, anti-patterns)
  - Understanding of React/Flux basics (e.g. child keys, anti-patterns, bastardizing with some weird approach)
  - Understanding of functional programming basics (e.g. immutablity, HOFs, pure functions)
  - Understanding of computer science basics (e.g. weird custom approaches that poorly mimic trees, no big-o concerns that hurt perf, memory leaks)
  - Separation of concerns (e.g. making UI components know about and concerned with the data persistence layer)
  - Security (e.g. secure credentials committed, pretty much an afterthought)
Are these issues simply the norm for frontend development and something I just need to get used to OR is perhaps my frontend network itself poor and something I just need to work on building up to more "solid" clients? I understand few companies are perfect and I am not asking for it all, but coming across clients with lapses in all these areas is what concerns me.

  • by angersock on 4/30/15, 7:49 PM

    So, a few of those are kind of elitist.

    React/Flux is still super new. Hell, there are like a dozen Flux frameworks out there with more on the way, and people are still arguing over what it looks like. So, you shouldn't ding people for that.

    Functional programming is something that, at least for what you've mentioned, is a nice-to-know and easily explained insofar as it matters to front-end devs.

    Security tends to be a rabbithole and something that, if taken seriously, can really slow down a project. So, it makes sense to market yourself as "Hey, I can backfill your security holes". No reason to be high and mighty.

    CS basics is something you can again explain, or charge a premium for.

    Devops is a pretty vague and bankrupt concept. Lack of automated deployments is not necessarily bad, it may just not be how they roll. Lack of automated builds and tests is a different matter. Deployment/adminny stuff is typically a pain point in any org, and it just sucks. Look at it as an opportunity on selling them how to do it the Right Way.

    The stuff that I would absolutely be concerned about would be lack of testing (if they won't even acknowledge the deficiency), the lack of understanding git and project management, separation of concerns, and the CSS/HTML basics.

    ~

    Long story short, though, is that it is exceedingly rare to see any shop that has everything on that list squared away--and if they did, they wouldn't be hiring freelancers to save their ass.

  • by nostrademons on 4/30/15, 7:34 PM

    The reason you're valuable as a freelancer is because you know things that their existing developers do not. Take this lack of knowledge as a gift: it's how you can add value to their organization and justify raising your rates. (You do want to select for companies that are open to implementing these dev practices, and sell them on the benefits up-front. But a company that wants to implement all of these but doesn't currently have the headcount for it is a gold mine. It's an opportunity for you to improve the efficiency of a whole team instead of just writing some code.)

  • by jdlshore on 4/30/15, 7:40 PM

    Poor practices are more common among front-end developers, partly due to people coming in from non-programming fields (graphic design, for example) and partly due to people who should know better saying "it's JavaScript, JavaScript sucks, fuck it, I'm not responsible."

    Don't get sucked in to the JS blame game. There are many excellent tools and libraries available (e.g., Karma for cross-browser testing; JSHint for static analysis; npm for installing and updating packages) and good practices are entirely possible. Keep up the good fight.

    I have a screencast series on this topic at http://www.letscodejavascript.com (subscription required) and an essay on tooling and workflow at http://www.letscodejavascript.com/v3/blog/2015/02/javascript... (free).

  • by eswat on 5/1/15, 11:30 AM

    While freelancing I’ve seen team members being oblivious to how much work would be involved in actually making an area of their product good and not realizing how badly techdebt can compound in the weeks and months ahead when not solved early (usually because “we need to move fast”).

    An example would be CSS. Many developers hate writing it and think it’s a trivial toy that even a monkey can write properly. Sure, to get something up and running it takes little effort to get the presentation right in CSS. But making something maintainable that won’t slow down your velocity after a month of adding/removing/modifying rules and class names is an entirely different thing. Yet I’ve rarely met a client that didn’t have a severe tech debt with their CSS – I’m usually not called in to fix that – even those with refined testing and devops processes. Though they usually believe that their CSS is fine.

  • by yayolius on 5/1/15, 12:32 AM

    About that: - Testing: Yes, for sure there is a lack of understandment in testing specially in frontend, here i have seen that a lot of the test depends on the framework that you are using, also testing in front is relatively new, and not really standarized.

    - Devops, well if you are not seeing test, very hardly you would see the value of continuos integration, and tipiclly this process involves a lot of backend and even some server configuration, and as many say in here most frontends right now come from design backgrounds.

    - Project management. This is more like a "company culture" issue, the way the do this mostly depends on how the rest of the company values this in frontend development.

  • by fmsf on 5/1/15, 7:27 AM

    Last summer we where actively recruiting (senior) front end engineers in London. To try to filter, part of the first interview consisted of very simple CS related questions:

    - JavaScript has a `.sort()`, if it didn't how (or what) would you implement it?

    - Can you explain briefly what a Linked List is?

    - Given that JS is all about Maps, can you describe me how an hashtable works?

    Sometimes just by asking the `.sort()` I got replies like "Why do I need to know that? the sort already exists! Sorry I am confused, I thought I was applying to a senior front end position".

    Regarding dev ops (even if just generating the build pipeline) I got answers like "No way! that is hardcore"

    Everything else also lacked overall, specially testing.

  • by benologist on 4/30/15, 7:51 PM

    You've pretty much described the frontier of modern web development, some of this stuff is still being defined, lots of it is yet to reach mass-penetration.

    It would be pretty nice if there was an "all of the above for dummies" guide.