|
Protocol7 posted:I mean, it doesn't have to happen today by any means, but I do want to start on the date I told the new employer and I'd want to give as full of a 2-week notice as possible. Getting your vacation paid out might be contingent on full two weeks notice, depending on your local labor laws. Just give your notice, even if you don't have have it written on a cake.
|
#
?
Apr 15, 2019 17:13
|
|
|
|
| # ? May 26, 2024 18:17 |
|
|
Munkeymon posted:Getting your vacation paid out might be contingent on full two weeks notice, depending on your local labor laws. The law in CO if I remember right is that they have to pay it out no matter what on resignation or upon termination. I've got a cool full month's worth of PTO accrued which will be nice. So, I'll just wait until this afternoon to do it.
|
|
#
?
Apr 15, 2019 17:41
|
|
|
Nice! 
|
|
#
?
Apr 15, 2019 17:47
|
|
|
Protocol7 posted:Would it be in bad taste to give my 2 weeks notice at the end of today, after I've already had a conversation with my manager regarding some unfortunate circumstances around my car? I have to travel to a city 60 miles away for PI planning which spand 2 days, but my car's in the shop, so they ended up getting me a hotel room and now I only have to worry about traveling up once and down once. Just  here. It is not bad taste. There's never a good time to do it and anyone in a professional environment would understand that it's just part of doing business. Don't gently caress up a new job to have an easier let down on a job you're already checking out of.
|
|
#
?
Apr 15, 2019 18:55
|
|
|
Protocol7 posted:Would it be in bad taste to give my 2 weeks notice at the end of today, after I've already had a conversation with my manager regarding some unfortunate circumstances around my car? I have to travel to a city 60 miles away for PI planning which spand 2 days, but my car's in the shop, so they ended up getting me a hotel room and now I only have to worry about traveling up once and down once. It sucks but in the grand scheme of things it's not a big deal.
|
|
#
?
Apr 15, 2019 22:09
|
|
|
The bandaid has been ripped off. My manager was a bit shocked, to be expected, but was understanding when I explained the new company offered more and gives me an opportunity to work with other technologies that are not present at my current company. Now's the part where I admit this was my first time quitting a job, ever. I'm such a greenhorn. 
Macichne Leainig fucked around with this message at 22:26 on Apr 15, 2019 |
|
#
?
Apr 15, 2019 22:12
|
|
|
Rocko Bonaparte posted:We're getting two years in on some internal tooling that does less than 50% for even the best-positioned subset of our customers. Whole sections of it are unused. A lot of this comes down to ingesting all these team's requests, removing all that contextual information, and then implementing them seemingly arbitrarily such that no particular team gets enough of an implementation that they're set to actually use it in their own production environment. Seems like the actual "development" part of "software development" is getting shafted here. I've been there with our product manager who seems to think that sitting down and actually planning what our software is going to do "isn't Agile" and wants us to basically develop based on a random ticket description that was jotted down during a demo. I've been trying to sell them on the idea of feature development based on user personae and iterative design documents, but all of those "take too long". The alternative being a feature developed from both parties' memory of a spoken conversation with no reference documents that invariably takes several weeks of rework once anything is done at all. But hey! Agile!
|
|
#
?
Apr 15, 2019 22:32
|
|
|
Protocol7 posted:The bandaid has been ripped off. My manager was a bit shocked, to be expected, but was understanding when I explained the new company offered more and gives me an opportunity to work with other technologies that are not present at my current company. You did well.
|
|
#
?
Apr 16, 2019 06:57
|
|
|
Volmarias posted:It sucks but in the grand scheme of things it's not a big deal. Nah, it doesn’t suck.
|
|
#
?
Apr 16, 2019 11:59
|
|
|
vonnegutt posted:I've been there with our product manager who seems to think that sitting down and actually planning what our software is going to do "isn't Agile" and wants us to basically develop based on a random ticket description that was jotted down during a demo. I've been trying to sell them on the idea of feature development based on user personae and iterative design documents, but all of those "take too long". The alternative being a feature developed from both parties' memory of a spoken conversation with no reference documents that invariably takes several weeks of rework once anything is done at all. But hey! Agile! This drives me insane. Not only does it not save any actual time because all its doing is offloading the work of figuring out what a feature is supposed to look like on whoever is implementing it (either on their own or by spending a bunch of time playing 20 Questions with whoever dreamed it up), it also adds a bunch of extra time at the end when you realize that it doesn't work the way someone imagined it was supposed to work but couldn't bother explaining.
|
|
#
?
Apr 16, 2019 15:33
|
|
|
Wallet posted:This drives me insane. Not only does it not save any actual time because all its doing is offloading the work of figuring out what a feature is supposed to look like on whoever is implementing it (either on their own or by spending a bunch of time playing 20 Questions with whoever dreamed it up), it also adds a bunch of extra time at the end when you realize that it doesn't work the way someone imagined it was supposed to work but couldn't bother explaining. I saw a case where a feature was worked on and evolved over the course of several iterations until the requested feature exactly matched an existing feature. That was fun. The users were happy, at least.
|
|
#
?
Apr 16, 2019 15:52
|
|
|
Wallet posted:This drives me insane. Not only does it not save any actual time because all its doing is offloading the work of figuring out what a feature is supposed to look like on whoever is implementing it (either on their own or by spending a bunch of time playing 20 Questions with whoever dreamed it up), it also adds a bunch of extra time at the end when you realize that it doesn't work the way someone imagined it was supposed to work but couldn't bother explaining. This development process is one of the reasons I quit my last job. The best part is when they ask for a feature, and you ask "do you really want x?", they say yes, you deliver x, and then they clarify that when they said x, and you asked all the details about x, they meant y, which is totally different, and also highly specific. The work I did wound up being so kludged together that I'm sure it had to be thrown out when I left. EDIT: My favorite part was i'd be given front end mockups with no explanation as to functionality, so I'd have to guess from an image what the heck pressing a button was supposed to do, or what data to display. TheCog fucked around with this message at 15:57 on Apr 16, 2019 |
|
#
?
Apr 16, 2019 15:54
|
|
|
not sure where else to post this, but today this mail arrived with the subject "This is not a recruitment message":quote:Hi Keetron, The pdf was a description of a generic dev role in a consultancy, it had absolutely nothing unique of enticing that would make me waste social capital for a few hundred euro's. No, not a recruitment message but spam aimed to have me do your work for you. Instead I wasted time on putting it on this here forums, but that is billable time too. Keetron fucked around with this message at 19:07 on Apr 16, 2019 |
|
#
?
Apr 16, 2019 16:07
|
|
|
TheCog posted:EDIT: My favorite part was i'd be given front end mockups with no explanation as to functionality, so I'd have to guess from an image what the heck pressing a button was supposed to do, or what data to display. Haha, i've been in that situation, where the mockups turned out to be 'just a guideline' and we (a team of backend dev) should magically know how it was supposed to work.
|
|
#
?
Apr 16, 2019 16:10
|
|
|
My favorite line from my soon-to-be-previous job is "The feature worked as expected...but not as the business expected."
|
|
#
?
Apr 16, 2019 16:41
|
|
|
raminasi posted:My favorite line from my soon-to-be-previous job is "The feature worked as expected...but not as the business expected." Wouldn't it be more like "worked as documented... but not as the business expected"?
|
|
#
?
Apr 16, 2019 18:32
|
|
|
Keetron posted:not sure where else to post this, but today this mail arrived with the subject "This is not a recruitment message": I think you still have your first name in there.
|
|
#
?
Apr 16, 2019 19:02
|
|
|
Mr Shiny Pants posted:I think you still have your first name in there. it is not a big secret but thank you!
|
|
#
?
Apr 16, 2019 19:07
|
|
|
A very broad question to the developers/engineers out there - how would you characterize the good (technical) managers you've worked with? And in contrast, the poor ones? I used to think in terms of smarts - technical know-how. As I've grown older and as I've moved up to managing people, I've become a firm believer in the touchy-feely stuff which can be hard to quantify e.g., leading by example, creating a positive environment, setting up projects for success etc. I've been musing about this a lot recently because of my current CTO who I'd summarize as an excellent engineer who's lost at managing teams.
|
|
#
?
Apr 17, 2019 02:44
|
|
|
shrike82 posted:A very broad question to the developers/engineers out there - how would you characterize the good (technical) managers you've worked with? And in contrast, the poor ones? Technically literate at least, but with actual management ability. And the desire and ability to defend the team and fight against scope creep. Anything else is a disaster. Your CTO is an overgrown senior engineer.
|
|
#
?
Apr 17, 2019 02:50
|
|
|
shrike82 posted:A very broad question to the developers/engineers out there - how would you characterize the good (technical) managers you've worked with? And in contrast, the poor ones? The best technical manager I've had was mostly decent at all the things Gildiss mentioned, but what I really liked was the importance he placed on gathering data. It allowed for quantifying success that I found really useful. And this was beyond silly quantities like lines of code, etc. Numerical quantification related to the intended purpose of software and how successful it was at fulfilling it's intended/documented purpose. I found it to be a really valuable lesson; probably one of the best manager type lessons outside of what Gildiss outlined. The worst thing about the guy was he couldn't or wouldn't fire lovely devs which is a problem I've seen in every place I've been.
|
|
#
?
Apr 17, 2019 03:21
|
|
|
shrike82 posted:A very broad question to the developers/engineers out there - how would you characterize the good (technical) managers you've worked with? And in contrast, the poor ones? In my experience, "leading by example" is usually not a good thing. It can create this weird situation where the technical manager overworks himself in order to try and motivate others, and others start relying on the manager too much for everything. Also, it has the potential to really frustrate the manager, because he'll be thinking "I'm working so hard to motivate everyone else, why aren't they getting it?". What I always ask from my managers is to very clearly set expectations and be brutally honest in feedback. If you're not happy with what I'm doing, don't try to motivate me by "leading by example", just be direct and tell me what you want from me. Work just seems to flow much better when the whole team knows what's expected of them and if they're meeting those expectations. With that in mind, here's what I think a good manager is like: 1) Their main focus should always be to build a great team. This means that when the team needs a new member, the manager needs to make sure that the right person gets recruited. Also, people who don't fit in the team get removed. And of course, the manager must ensure that all team members have the resources for constant self-improvement. 2) They need to stay out of the day-to-day work of engineers. A manager doesn't need to "OK" everything or always know what every single team member is working on every hour of the day - this is just stupid overhead. 3) Like I said before, they need to be clear about what is expected from the team. 4) They need to be constantly removing any obstacles from the team's way. Ideally, they'll be dealing with problems before the team even knows about them. From what I've seen, very few managers are actually like this, but the ones that are have definitely been amazing to work with. sunaurus fucked around with this message at 11:42 on Apr 17, 2019 |
|
#
?
Apr 17, 2019 08:32
|
|
|
I think that's fair although my thought about leading by example would be the exact opposite - managers that talk about work environment and work-life balance but themselves are always crunching, that to me would be the exact opposite of leading by example.
|
|
#
?
Apr 17, 2019 09:00
|
|
|
sunaurus posted:1) Their main focus should always be to build a great team. This means that when the team needs a new member, the manager needs to make sure that the right person gets recruited. Also, people who don't fit in the team get removed. And of course, the manager must ensure that all team members have the resources for constant self-improvement. It makes for diverse teams, which is like exercise something you never want before starting with it.
|
|
#
?
Apr 17, 2019 12:00
|
|
|
What do you do when you want to remove people but don't have anything to replace them with? I mean I'm in the remove them anyway camp but I've seen this scenario play out a couple of times and it usually goes:  , a manager , you, victim : we can't remove $dev, we've no new applicants for the open positions : why not pay more or offer to train people for the position then? : no, people must be perfect cheap developers from the word go
|
|
#
?
Apr 17, 2019 12:14
|
|
|
Boiled Water posted:What do you do when you want to remove people but don't have anything to replace them with? Easiest thing to do is 
|
|
#
?
Apr 17, 2019 12:21
|
|
|
Boiled Water posted:What do you do when you want to remove people but don't have anything to replace them with? I've gone through this once, it took ~6 months, and it went roughly like this: For the first few months, we did our best to onboard a new dev (who was actually an old dev in the company but new to our team), but we kept gradually running into weirder and weirder problems with him: 1) He insisted on using a different IDE than the rest of the team (not a big deal in isolation but it kept causing weird problems for him) 2) He used a local mercurial repo which he synced to our remote git repo (again, caused some weird problems) 3) He kept insisting on keeping all communication to phone calls instead of using async communication methods 4) In the same vein, he basically had his own version for every single tool or process that our team used and he always got visibly upset when something he wanted to use was incompatible with what the rest of the team was using 5) He lied a lot about his progress with different tasks and even what he was actually working on (this was the major problem with him really, but we didn't figure it out until a few months in) - he would say on a Monday that he would work on some feature which was blocking someone else, and then later that week we would ask him how it's going and he would shock everybody by saying something like "yeah it's pretty good I can start working on it probably tomorrow" We tried a few different things, early on we were all pretty optimistic that we could accommodate him and that he would come around to our way of doing stuff if he ever felt his way was causing too much friction. In reality, his productivity never went up, he kept stubbornly using his own tools for everything and having problems with them, and we even noticed that the rest of the team was also losing a lot of productivity because we were spending time dealing with him in different ways. I think he had been in our team for around 4 months when we decided that we didn't want to work with him anymore. We had plenty of data about how he was bringing down the productivity of the team (we were doing scrum at the time, so we could show a lower velocity, but also we had documented just a bunch of different ways that he had been causing problems for the team). It took another few months of management and HR talking to people in our team and the dev in question, trying to find solutions other than getting rid of him, but eventually management agreed with the team and we got rid of him. On the one hand, I'm quite proud of that team for fixing its problems even if it means firing someone, but on the other hand, 6 months is probably way too long to handle someone who is bringing down a whole team.
|
|
#
?
Apr 17, 2019 12:48
|
|
|
sunaurus posted:(who was actually an old dev in the company but new to our team), HR wanted to be sure they were safe against an age discrimination suit?
|
|
#
?
Apr 17, 2019 15:24
|
|
|
sunaurus posted:3) He kept insisting on keeping all communication to phone calls instead of using async communication methods 1. Only IM'ing "hi" and then not saying anything else until you hi back or whatever. 2. Then insist on having a quick chat that involves a phone call. I hate myself for it because I'm remote to this person, but there's a non-trivial amount of stuff that I could answer from them using IMs or email. They're not even blocked by me. Also, people seeing something on the command-line that send a screen shot of the command window instead of pasting the text. Love that.
|
|
#
?
Apr 17, 2019 15:39
|
|
|
How did it go down? Was he put on a PIP?
|
|
#
?
Apr 17, 2019 15:40
|
|
|
Rocko Bonaparte posted:Also, people seeing something on the command-line that send a screen shot of the command window instead of pasting the text. Love that. One of my (non-dev) coworkers regularly sends me PDF's that contain scanned printouts of screenshots.
|
|
#
?
Apr 17, 2019 16:36
|
|
|
Volmarias posted:HR wanted to be sure they were safe against an age discrimination suit? lifg posted:How did it go down? Was he put on a PIP? I don't know the details of what went on between him and HR sadly. He found out he was leaving before the rest of the team did, I think most of the team awkwardly heard it directly from him and he didn't really share much details.
|
|
#
?
Apr 17, 2019 17:22
|
|
|
Rocko Bonaparte posted:1. Only IM'ing "hi" and then not saying anything else until you hi back or whatever. That drives me insane. http://www.nohello.com/ I've tried to gently push my organization toward, "<pleasantries/greetings> \r\n <question/request>"
|
|
#
?
Apr 17, 2019 17:23
|
|
|
It's downright unprofessional to use chat in a way that is not stream of consciousness
|
|
#
?
Apr 17, 2019 17:32
|
|
|
CPColin posted:One of my (non-dev) coworkers regularly sends me PDF's that contain scanned printouts of screenshots. I was trying to find a reasoning for this but then the depth of steps started to dawn on me . I mean wtf?!
|
|
#
?
Apr 17, 2019 17:52
|
|
|
I deal with people who don't know how to use chat or want to have long, drawn out phone convos by saying something like "Hey there, I'm really busy today, could you just send me a quick one liner with what you need? Thanks!" and it has *drastically* cut down on the amount of bullshit I've had to deal with. Also I left my desk phone unplugged for about a year, that helped too
|
|
#
?
Apr 17, 2019 17:58
|
|
|
sunaurus posted:I've gone through this once, it took ~6 months, and it went roughly like this: If I know what IDE my coworkers are using, it's a problem. I worked on one project where a couple of devs kept checking in IDE specific files into our git repo. Then, of course, when I would not have them it would cause merge conflicts. I tried to tell them how to use gitignore but then they found out I wasn't using their IDE and got all huffy about it. It was weird.
|
|
#
?
Apr 17, 2019 18:18
|
|
|
downout posted:I was trying to find a reasoning for this but then the depth of steps started to dawn on me . I mean wtf?! They're sometimes annotated in ball-point pen, which makes the extra steps slightly more worth it, but I'm guessing my coworker learned the keyboard shortcut for "actually print the screen" vs. "copy the screen to the clipboard" and has never seen a need to do anything differently.
|
|
#
?
Apr 17, 2019 18:29
|
|
|
vonnegutt posted:If I know what IDE my coworkers are using, it's a problem. I don't agree - if multiple people in the team (the majority?) want to use a jetbrains IDE, then it makes perfect sense to check in the .idea folder. How would this even cause merge conflicts if you don't have a different local copy of the files? That would be a conflict-free merge. In the specific team I wrote about, we had for example shared stuff like our code autoformat settings and a bunch of database connection settings. We never forced anyone to use intellij, but since everyone preferred jetbrains IDEs, it made sense to share the settings. The new guy wanted to use eclipse instead, and we definitely didn't tell him that he couldn't, but he ran into a bunch of problems with getting his editor to not reformat all of our code on all his commits and he also had some problems with getting live reload to work (everybody other than him used the jrebel plugin for intellij and nobody knew how to help him troubleshoot it on eclipse). Keep in mind, I only brought the IDE thing up to paint a better picture of how he wanted to do everything his way. I'm definitely not saying that people using different IDEs in one team is somehow inherently bad for team productivity.
|
|
#
?
Apr 17, 2019 18:43
|
|
|
|
| # ? May 26, 2024 18:17 |
|
|
Using different IDE's depends heavily on not having a completely broken build process, too. When I worked at Experts Exchange, we went from having a pile of JAR's in a lib/ folder to using Maven for our dependency management. We never quite figured out how to use Maven to actually build things, because we were all using Eclipse and it just refused to get out of the way. We were also using JRebel for hot-deploying to our Dev servers (which we couldn't run locally). So we ended up with a very Eclipse-centric build process (we even used the ECJ compiler on our build server, because of weird incompatibilities with javac and generics) and no hope of ever letting anybody use another IDE.
|
|
#
?
Apr 17, 2019 18:50
|
|