Fork me on GitHub

I'm with @wesley.hall on front-end difficulty - never mind the incidental complexity of the js ecosystem, I have good solutions for all the things I need our backend to do - I just don't have a good solution for the front end. re-frame & reagent are ok, but the fundamental ops don't seem to compose well, and I don't yet know what will

👍 5
Wes Hall01:02:41

Even the testing story on the FE is much much much more complicated. Not only do you have the problem of how to emulate the browser (and which browsers to emulate), but there is no implementation for a unit test named, "ensure-ui-doesnt-look-like-shit".

Wes Hall01:02:17

Maybe this whole, "FE is easier" is just a psychological trick.


Re FE testing, @dominicm mentioned to me about a week ago. I think it was discussed on this slack somewhere.


So I think the reason FE is a gateway to engineering is because the feedback loop is so tight


I think the only time I've experienced a similar feedback loop is repl driven development


And that feedback loop is needed to get beginners into flow


Once they're there they'll start to problem solve and be effective


I've seen how difficult it can be to teach apprentices and both of the current python apprentices at the old place switched specialism to front end


I think it was because they felt they could see the results of their work more easily


(I really should have tried them on clojure but I wasn't mentoring either troll)


But then if you have lots of junior folks doing a thing, it makes it look easy


Well, gives it the perception of being a thing that new engineers can pick up quicker than back end and like I said I do wonder if that's just because of the feedback loop issur


I just completed a rotation on an app that was 90% front end, like a progressive mobile app type thing, and we had to get our best people on it, with the best contractors we had on the assignment board because doing it right was so hard!


So I think at the planning/capacity/team lead level we were super aware that it should be taken really seriously, but I don't know how common that is in the wider industry


NOW, a caveat


I have also had to deal with more amateur hour rubbish on the front-end than on the back. We've got badly designed backend solutions here and there, for sure, but when a design contractor comes in and says they're also good at front end (engineering don't vet design hires) and their scope drifts, we end up with all manner of messes.


My favourite just in the last week was an entire frontend for a critical project written as a single js file (2800 lines) with no tests


Nobody noticed because everybody just assumed they knew what they were doing and didn't interfere (that's as much the failure in my book, always peer review etc)


I've had proprietary code pushed to npm and all sorts, sometimes knowingly, sometimes unknowingly


But I think on higher performing teams, devs, designers and (well as I've revealed I think all devs should be able to do some front end) front enders should be working together, rubber ducking and/or reviewing and/or and pairing so that they're continually socialising and sense checking their work

Wes Hall13:02:23

@alex.lynham Definitely agree with you on everything there. I think it also highlighted and extension to what you said in my mind which is that FE is much more likely to turn into a "camel" of "design by committee" fame. I think one of the reasons I tend to prefer doing backend work is that people are much more likely to describe problems to me, and let me build solutions. I like this simple arrangement. When it comes to FE though, everybody throws solutions around. FE feels "penetrable" to most people. They might not understand REST or GraphQL but they have definite opinions on colour schemes and layouts and I don't think that UX has been pushed hard enough as an "objective discipline". A science. There is also (as is nearly always the case in all forms of software development), this problem that the things that seem like they would be easy to build to the laymen, are the harder parts and vice versa. When I write back end code, I know that I can build something solid, that is unlikley to change on a whim, but when I build FE code I might have to please Steve from accounts and hear about what he preferred in his cousin's e-commerce wix site. I wonder whether this influences a lot of the "short-termism" of some FE teams. Constant moving target etc etc.

💯 15