Clojurians Log v2
jobs-discuss
Apply for Clojure jobs :)
Also, implement something in Clojure in your preferred domain. While Clojure experience is a plus when we hire, being interested and a good learner is so much more important.
I guess the worry is, if someone has 15-20 years of development experience, they don't want to be beginners again with beginner paycheck
That is a real concern: if you change tech completely, companies often expect you to come in as a "junior". That's a flaw in how we hire -- if we are willing to do any training, then a truly "senior dev" should be "senior" regardless of tech because what they bring to the table isn't their expertise in Language X but their expertise in development (and maybe architecture) as a whole. Or at least it should be.
I think it’s a huge difference between changing from Java to Clojure and eg from web-dev to embedded
Agreed, but not every knowledge is translatable to other languages. If someone worked 15 years at a single company on a single architecture that was built organically in-house, it's fair to say that they will have less knowledge of what is going on than someone who did what is a less appealing story: went and worked for everyone at every job.
You might say they have "one year" of experience, repeated "15 times". 🙂
you must realize though that we (myself and these people who unlike me, switched jobs just for better pay - I only left if it seemed pointless to stay), started with paychecks around $130/month, about 15-16 years ago. Sure, that's beginner salary even in romania, and it's after taxes, but I hope it's clear why would some people get into a habit of switching jobs for money if that's the only way to get a better pay where you are coming from.
I switch jobs on average every 18 months, and that's because generally unless it's project/agency work I hit diminishing returns. I'm good at early stage projects but less good (or frankly, that interested) in longer term stuff. In the pioneer-settler-town planner model I'm a pioneer and have built my career on being able to get things together that will scale well and hopefully be a good foundation to build on
so you don't work more than 18 months with the same people at all? no long term work relationships?
nah I mean I stay in touch with people pretty well, I'm currently working with some folks I've worked with before. If I like people I'll make an effort to stay in touch, get lunch etc, but work is work, ya know?
I make friends with people that I like when I work with them, but if we get on, that doesn't change if/when I go (I hope - and experience seems to confirm that)
work is work? no, i don't know. care to elaborate?
well that it's only a part of your life, and there's more important things - friends being one of them
well, that's certainly true, but how about if I say that all parts of my life add up to the whole thing, and thus, all are equally important?
so, I don't really understand what you are trying to say, but I am exceptionally curious.
okay well I obviously don't take it that seriously, not all parts of my life are equally important. it's how I make money, I do a good job, I'm a professional with pride and standards, but where I work isn't as important as what I do, which is make stuff
so what I'm specifically saying by 'work is work' is that is a workplace which is very distinct from the work that I do
and I'm not attached to a single workplace
That's an interesting choice @alex.lynham -- I guess I'm in the opposite camp: since we spend about a third of our day working, I want that part to be as enjoyable and as convenient as possible, so I want an employer that understands and supports a good work/home life balance and offers plenty of flexibility. In addition, I like seeing large, complex projects come to fruition and as an architect I've overseen several projects that stretch out over multiple years. When I find a job that satisfies both of those, I'm likely to stay there.
My first job lasted four years (walking distance from home, very flexible environment, interesting projects that took time to build), my third job was four or five years (lots of global travel meeting interesting and varied client, really fun colleagues -- that I've stayed friends with for decades since!). I was at Macromedia for six years (nearly seven if you include the time after Adobe acquired them -- but I view that as a one year job that I wasn't happy with). I've been with World Singles Networks for about a decade -- super flexible about time, several multi-year project roll-outs.
In amongst all that, I had several years as a freelance consultant in England and several more years in California, mostly while I was looking for the right "next job".
I don't think we're disagreeing, necessarily. I like to have those things too - but for me I guess I don't get the long term satisfaction from seeing a product over a long period in the same way. I get itchy so I want to work on a new product or domain to learn something new, get a new perspective.
I have a couple of my own tinkering things that I've chipped away at for years though, so maybe one day I will build a product I want to shepherd for a longer period :)
And to be fair I worked at swirrl (my first clj job) for nearly four years, but that was agency work so plenty of variety. A little different to one single product or project
An interesting point relating to this thread was raised in this talk https://youtube-cutter.org/video/rOKSe2vOr (you can get the original from this cutter page, I didn't want to share an hour for a couple of sentences) But you can find the gist in this tweet: https://twitter.com/ICooper/status/1004757312374886400
@slipset Which of those shifts do you consider to be "too big" to be useful/valid?
The domain shift.
The language shift I consider trivial.
Browsers are resource-constrained -- they are a form of "embedded system".
I was thinking more in terms of bit fiddling, memory management and such.
Like low level C programming.
I think that is good background knowledge to have for any software position (but it is sadly rare these days).
still better than the same experience for 15 years without change
I've done embedded systems -- my team at Vodafone were the first in the world to create pay-as-you-go cell phone systems -- and compilers and web apps and a bunch of other things. I don't believe good software folks are confined or constrained by domain.
but yeah, I am also worried how people will settle down if they are used to switching jobs every 6 months as some of my friends appear to be doing (very productive, you get much better salaries much faster)
low level as in know thy hardware?
or low level as in we somehow believe that C is simpler than lisp? 😄
Salary isn't everything (well, sadly, for some folks it is).
I am bewildered by people who switch jobs regularly after less than a year (I don't think I would hire anyone who did that).
So if I were to apply for jobs (I'm 49 years old, been programming professionally for about 25 years mostly in backend web-dev, using Perl, Java, Javascript, Clojure and Clojurescript, throw in som ops and database stuff as well): 1. Any backend web-dev job, regardless of language, I'd expect that my experience counted. 2. Frontend architecture/full-stack web-dev, I'd expect that my experience counted 3. Pure frontend/UI/UX, wouldn't apply because a) I know my limits, b) I'd only be able to get junior positions and thus a pay cut 4. "Closer to the metal" programming, wouldn't apply because I'd only be able to get junior positions because the experience I bring to the table is not that much worth
So if I were interested in transitioning, eg to a pure frontend dev ie 3), I would start that transition in my current company, and then when/if I became sufficiently good at it, I'd apply for external positions.
I can understand the hire worry to some degree, but not the difference between BE/FE. After doing lots of backend jobs and lately doing mostly frontend, I don't understand the distinction in people's head between the two works. Basically, the only clear difference I see is that backend devs - unless they work on highly concurrent systems or security or database management at scale, or something that's relatively rare, are having it much easier. They always have a single environment to consider, and they only have to write machines that talk to other machines. Frontend devs environment is "any device running a browser", and you have to talk to a human.
But I bet no "backend dev" would agree with this 😄 Usually, the attitude is that I am a javascript developer so I must be a script kiddie, and serious programmers write serious programming languages like python. Or java.
As a backend-dev I'd say that full-stack frontend is a lot harder.
Especially if you code in javascript.
@ashnur having done only backend for many years and now doing both (backend and frontend), I completely agree with you; frontend is a harder thing to get right and it’s much more nuanced than backend
To me the distinction is between the frontend of the frontend and the backend of the frontend. If you think of this in a React-setting, the frontend of the frontend would be the creation of the react-components. This is work that I consider highly "visual" and (to a certain degree) is simpler, coding wise, basically it's a function that takes some data and transforms it to html. The backend of the frontend is where and how you manage state in your frontend, and also how you communicate with the backend. This has, as I think we've seen, some interesting architectural challenges.
Depending on how you look at it the backend of the frontend is basically backend work with a shitty language on top of either a bad cache or a database with high latency and a shitty query-language.
I think there's no right answer, it depends.
@mpenet you must be an expert 🙂
some backends can be extremely complex (in both logic, size), same for front-end
🙂
front end has way more state than backends though, for all kind of user interactions
depends
as I said it's not white/black
but one can say that backend has complex business logic as well, but I will take that anyday over a highly interactive front end
I'm sure one might argue that a lot of frontends are overly complex. Ie why use javascript at all if all you have is a mail-form?
But I think we might be moving into #off-topic land.
backend for a todo list vs backend(s) for a cloud platform, front-end for gmail vs x, etc etc
indeed #off-topic
imo you can control the environment and input for backend but not for the frontend
which makes them wildly different beasts
I wish! The number of times I've had to interface with a badly designed external API that I have zero control over is without saying - and the explosion of internal microservices that all seem to have their own interpretation of what REST means (I'm just as guilty!) 🙂
Control is locally scoped 🙂
backends have databases and orms, on the frontend I am frowned upon if I want something that's more than promises but less than rx.js or mobx or xstate.
We have to support IE, so I can't add a serviceworker because then it's two products. Meanwhile, although everyone realizes that while you can connect in a sync way to your database and run queries, 1. in the browser it's not possible 2. even if possible, no one would use an interface that blocks, so the idea that because js is single threaded, you don't have to do concurrently things is bollocks, but try using CSP in javascript and people will call you crazy (happened to me, sorry for the harsh words), because "that's overkill!"
I considered before sending this message if it fits this channel, and I have to say it does because I really wish there would be more job options where the long term is considered
I agree, frontend work, targetted towards browsers sucks eggs 🙂 I don't mind writing javascript for server-side stuff 'tho 🙂
but there even php is enjoyable, in such a controlled environment
I find it a bit strange that some people refrain from the hard work 😄
programmers are inherently lazy 🙂
Who else would spend 1 week to code something automated up to save 1 minute’s worth of time… :D
the only con is backend visualization tools kinda suck so we’re stuck with cli niceties
there is a lot of con in this
e.g. we have only a single web browser
so a single runtime environment, which lends the necessary context that explains why js is successful. The minimum deployment time for this single runtime environment
oh, and what is bothering me most is that the backend devs who sometimes have no real experience with browser work then go and limit what the frontend dev can do purely on idealistic grounds. I am in this situation at my current work and it's quite frustrating at times, although again, it was a good learning experience, I discovered new limits in self control
#triggered
I draw a distinction between 'web backends' and 'non-web backends'. The first you can often operate under the illusion that your code is single threaded while on the latter a back-end without concurrency is in my experience not very common.
@alwyn I think that might be accurate. I am curious what do you think the jobs ratio is, that is how many hours are spent working in each, globally, at any time scale you might hazard a guess? 🙂
I was thinking of implementing a basic REST service to get stock data and render it in a nice way. Does that seem reasonable for a project?
I think it leans, perhaps heavily, in the web-backend direction due to web being the preferred interface into services. Depending on industry or domain non-web backends are usually where large volume processing happens or integrations between systems, with hardware, etc. At 47 I've been going about this for 30 years, probably a 40% web split for me and I prefer the non-web since often its more challenging (and frustrating at times).
I am only in it for ~16 years but I would say it's probably even more. Also I think this ties back to the taylorism, because most of what you call web-backend I would characterize also as repetitive. Similar trends are on the frontend served by for example TypeScript. It's really a different kind of programming. It's not about finding and solving challenging software problems, rather, as not so long ago someone told me "building products". This is a recurring theme, how productive these people are for their employers compared to me at least 🙂.
Those that need to care about what they do and those that don't?
Best not to assume we know "why" people do things. It's bad enough to generalize.
I'm talking about my own experience, no matter how hard I try I cannot get myself to not care about what I do.
I got that, but I wouldn't want to make that kind of generalization from my own experience to someone else's experience, I don't like it when other people do it with me either.
Totally agree. The repetitiveness is getting to me. Made worse by all the extra baggage we add to it. Clojure (and to a lesser degree Kotlin) appeals to me because the ideology cuts through all the bull down to the essence of "what do I want to do with this data". I'm a clojure noob by all measures, but I'm hoping to make something of it some day.
case in point https://clojurians.slack.com/archives/C0KL616MN/p1591283869485300?thread_ts=1591251381.430100&cid=C0KL616MN
@alex.lynham do you make the same stuff twice?
A lot of the problems are the same from a big picture perspective, but no I don't really make the same stuff twice. Depends what you mean though. If you count 'any backend work' as the same thing then yes I do
@alex.lynham I am trying to make the case that there are two entirely different kind of classes of programmers, one that tries to make money and doesn't mind programming and one that tries to program and doesn't mind getting paid 🙂