Fork me on GitHub
#jobs-discuss
<
2016-03-06
>
alandipert00:03:17

having fun as a group is work to the extent it results in a more cohesive team, no?

hiredman00:03:39

sure, but that isn't the goal for a company right? you are employed by a company because they need some software, the cohesive team is a means to that end

hiredman00:03:55

and those weeks ended up being all fun, and no software

alandipert00:03:58

and so then is having fun periodically

hiredman00:03:26

my point is, from the management perspective, they thought it was great that they could look out over a buzzing office, but very little software was being written

alandipert00:03:09

i get it, have observed same phenomenon

alandipert00:03:42

out of curiousity, on your all-remote team, was there anyone on the team for whom the job was their first programming job?

alandipert00:03:04

were you the only one?

hiredman00:03:27

I am not sure

hiredman00:03:05

I vaguely think one guy was in more of a sort of it support job before us

alandipert00:03:06

i think you are the first person i've ever had the chance to chat with about remote who was brought up on it

hiredman00:03:09

it changed, you know, as the company did, we had the entire management team change over us

hiredman00:03:53

from my perspective, the remote was great (is great, the idea of having to pick up and move to get a job is just terrible), I think the informal structure was more of an issue

hiredman00:03:42

companies continue to run beyond any one person's job with the company, so if you don't codify some kind of roles, when new management comes in they won't know anything

hiredman00:03:23

I could sort of see that maybe being less of an issue in an office, where you can see things happening, but the formal structure is also helpful for employees when they leave and get jobs else where

hiredman00:03:12

we didn't have any formal notions of "senior dev", but if we did, I like to think I would have been one, and it would be nice to put "senior dev" or whatever on my resume

hiredman00:03:03

(of course location has turned out to trump anything else on my resume)

sveri08:03:46

Working in a mixed team with part of the team being overseas I can just restate my experience.' 1. Being split is not a problem for us, work is split also, during feature implementation there are regular sync calls ranging from 1m to 2h and after the implementation there are technical team demos 2. Here I am required to be onsite most of the time. Last week was the first week ever I was alone in my office (due to holidays and stuff) and it was my most productive week. Not only that, the feeling of having been very productive was just another boost to my productivity in itself, it felt awesome. 3. Being in the office for us means there is always someone coming along who is bored (maybe because of wait times and stuff) or who has a problem that might take him 10 minutes to research but only 1 minute to ask someone else. For me this means constant disturbance ranging from 5 times to maybe 20 times a day leaving me in a weird state because I always have to get back to where I was before. 4. I don't need that "fun" stuff. I take it if I can get it, but having the choice between working remote or mostly alone and all the "fun" stuff I choose working remote every time. For fun stuff I have family and friends and not some setup situation where HR puts up some "events"...well, you know what I mean. Also I dont get why more offices try remote work, especially for senior devs that know which way to go and what to do. And I am not even starting to talk about the environmental effect of all that commute that has to happen for onsite work, or the stress you have sitting in a car every day fighting the other drivers about being 1 minute faster and whatever else happens on the street^^

onetom14:03:26

@lmergen: i guess we shall continue the discussion here

lmergen14:03:52

@onetom: well it's interesting to see that many people find creative solutions to this problem

lmergen14:03:18

for me right now, it's a decision whether i want to make a safe choice (go with java, because hey, there are java programmers everywhere) or go with clojure

lmergen14:03:38

i'm pretty sure going for clojure and setting up a culture of "learning while working" is the best, but i have other people in the organisation who want to get things done as quickly as possible (sales :)), so it's a kind of battle i need to have the right arguments for

onetom14:03:47

that's the same story everywhere i guess

onetom14:03:28

what i did is we agreed on helping sales by producing non just mockups, but actual web interfaces with hoplon, what sales could present in sales meetings

lmergen14:03:53

hmmm we have a strict separation between front-end and back-end

lmergen14:03:59

so we run pure javascript on the frontend

onetom14:03:10

actually thats how the team got trained in clojure in the 1st place because writing frontend code allowed immediate feedback

lmergen14:03:11

that communicates with a clojure backend

lmergen14:03:30

yes that's good, i already forced the team to use React simple_smile

lmergen14:03:53

so they already learn about some of the concepts now

onetom14:03:58

that's what i was almost choose too, but found hoplon (and boot) luckily 😉

lmergen14:03:25

yeah i can't do that to my frontend team, they're too junior

onetom14:03:52

i looked into om and reagent and some other react wrappers but they were all beyond the capabilities of my initial team so i choose hoplon with the caveat of potentially dropping it in 2-3 months if it turns out to be insufficient for more complex scenarios

lmergen14:03:15

yeah i can't afford 2 or 3 months to lose right now

onetom14:03:28

it never happened. 1.5yrs later we are still on hoplon and quite satisfied w it

onetom14:03:59

and indeed it was a lot easier to pick up hoplon than react

onetom14:03:03

by easier i mean 1-2 days

lmergen14:03:43

well, we have one of the main guys behind react remotely mentoring our juniors right now

onetom14:03:50

but anyway, u said u r looking for a senior backend dev

onetom14:03:55

sounds expensive simple_smile

emperorcezar15:03:11

The only time "as fast as possible" is acceptable is being an early stage start up. And even then you have to prepare for it to bite you later.

emperorcezar15:03:04

I speak from experience

lmergen15:03:44

guess what i am working at... an early stage startup that actually just got its seed money last Tuesday simple_smile

lmergen15:03:06

but i am here to un-fuck what previous, cheap, outsourced developers have done

lmergen15:03:20

which means throwing away an epic 100k LoC php codebase

tjg23:03:32

On the previous discussion, I have experience doing “semi-remote”: I’m in the same city but can choose where/when to work. Based on the situation (and social decisionmaking), not workplace dogma.

tjg23:03:35

“Onsite” has many constraints. It’s rarely done well; for example, performance is measured in sit-in-front-of-computer much more than other factors. (If everyone says great ideas come to them in the shower, why don’t they spend more time near a shower?)

tjg23:03:38

And “onsite” communication ironically usually lacks empathy: do people learn how their coworkers prefer to communicate, like Alice prefers email while Bob’s ok with physical interruptions? Do they respect you enough to put your answers in the wiki/docs (or screencap a video), so you don’t have to repeat yourself?

tjg23:03:41

So I suspect “offsite” is often code for “You can avoid many typical dysfunctions!”

tjg23:03:44

(Obviously, semi-remote has its own dysfunctions to solve too. Coworkers occasionally chilling at each other’s apartments can be uncomfortable or lead to cliques. But then again, I’ve been in traditional dev offices with posters of scantily-clad women. So.)