|
Jaded Burnout posted:I've gotten my last two remote jobs through, ironically, a regional users group for the language I work in. Yeah, I used to run our local Ruby user group, and I'm currently running our local Elixir meetup. The local Elixir market is super tiny, and I think I'm going to have to go remote for a gig, unless I dig up a new client that doesn't care what their stuff is built in. It's tough, though! I'm an independent contractor/consultant, and I'm starting to roll off my client of 3 years. Hopefully after the holidays some more leads will start to roll in.
|
#
?
Dec 19, 2018 18:03
|
|
|
|
| # ? May 27, 2024 08:28 |
|
|
manero posted:Yeah, I used to run our local Ruby user group, and I'm currently running our local Elixir meetup. The local Elixir market is super tiny, and I think I'm going to have to go remote for a gig, unless I dig up a new client that doesn't care what their stuff is built in. I had a client ask me to do their thing in elixir but I steered them to ruby instead. I do both, but I’ve not honestly found a lot of use cases where BEAM is actually the right thing for people.
|
|
#
?
Dec 19, 2018 18:20
|
|
|
Jaded Burnout posted:I had a client ask me to do their thing in elixir but I steered them to ruby instead. Yeah, same. Another thing with recommending tech for clients is them being able to find developers after I've gone, so it's tricky. Might just end up having to go work somewhere that it's already being used.
|
|
#
?
Dec 19, 2018 19:05
|
|
|
manero posted:Yeah, same. Another thing with recommending tech for clients is them being able to find developers after I've gone, so it's tricky. I am looking at your post history and I think we agree on a lot of development things.
|
|
#
?
Dec 19, 2018 20:49
|
|
|
I turned down a remote job for $110+benefits this morning. I feel like 16-year-old me would be proud for sticking to my guns and not taking an easy win.
|
|
#
?
Dec 21, 2018 16:46
|
|
|
Careful Drums posted:I turned down a remote job for $110+benefits this morning. I feel like 16-year-old me would be proud for sticking to my guns and not taking an easy win. What was the sticking point?
|
|
#
?
Dec 21, 2018 17:42
|
|
|
Munkeymon posted:What was the sticking point? It was only one hundred ten dollars per year.
|
|
#
?
Dec 21, 2018 17:44
|
|
|
CPColin posted:It was only one hundred ten dollars per year.  would be pretty good pay for my market
|
|
#
?
Dec 21, 2018 17:54
|
|
|
Munkeymon posted:
I'm impressed that you can live on less than a fourth of what the people in the poorest country in the world make (Democratic Republic of the Congo, average USD 439/year).
|
|
#
?
Dec 21, 2018 18:06
|
|
|
Problem was that the company was too small I guess. Only one other technical person and after spending an hour on the phone with him, I felt I would be learning nor being challenged by him. So low challenge + first full time remote job seemed like a likely disaster for me.
|
|
#
?
Dec 21, 2018 18:20
|
|
|
Munkeymon posted:
It was a joke about only making $110/year and not $110k/yr
|
|
#
?
Dec 21, 2018 20:01
|
|
|
Slimy Hog posted:It was a joke about only making $110/year and not $110k/yr  too real though
|
|
#
?
Dec 21, 2018 20:05
|
|
|
TooMuchAbstraction posted:Getting comfortable in your career means at least some degree of stagnation. I'm not saying you shouldn't ever feel comfortable -- if you enjoy the work, are sufficiently well-compensated for it, and are reasonably confident that there's long-term demand for your skills, then feel free to stagnate all you like. Just be aware that that's what you're doing. Thanks for pointing out to me just how much I’ve stagnated. And I really have no idea about what I should do about it, or even what I want to do. I pretty much do one thing (well). But I make a good day rate, there’s more than enough work out there, but it’s not overly challenging in a good way, mostly just a case of knuckling down, wading through the poo poo, and finding out how to do the work clients need. That said, I’d happily stagnate if it meant working less, but everyone seems to want a 9-5/5 developer. Any other career contractors successfully broken out of easy-money stagnation? Or cut a path into silly-money consulting?
|
|
#
?
Dec 21, 2018 20:32
|
|
|
Horse Clocks posted:Thanks for pointing out to me just how much I’ve stagnated. No, I'm in the exact same situation as you. I keep saying I'll take more time off during the year but that's not really compatible with pouring money into the pit that is my house. What would you consider "silly-money"?
|
|
#
?
Dec 21, 2018 20:36
|
|
|
Jaded Burnout posted:What would you consider "silly-money"? I assume silly-money is the kind of bill rate that Patrick McKenzie gets https://training.kalzumeus.com/newsletters/archive/consulting_1 quote:in my spare time, I run a high-end software marketing consultancy. It is modestly successful: I make my clients millions of dollars and charge mid five-figures a week.
|
|
#
?
Dec 21, 2018 22:55
|
|
|
kitten smoothie posted:I assume silly-money is the kind of bill rate that Patrick McKenzie gets Hmm! I am, coincidentally, at the point where I either have to turn down actual real work (not just vague job offer suggestions) or hire someone, though my main clients so far have been either day rates or individuals who don't have the budget to crank rates sky high. I really don't want to hire someone.
|
|
#
?
Dec 21, 2018 23:44
|
|
|
Jaded Burnout posted:Hmm! I am, coincidentally, at the point where I either have to turn down actual real work (not just vague job offer suggestions) or hire someone, though my main clients so far have been either day rates or individuals who don't have the budget to crank rates sky high. I really don't want to hire someone. I think one of the secondary points of that article is that even if you don't increase your rate, switching from hourly billing to weekly billing can increase your revenue and reduce your stress. But you would have to restructure project plans as well to account for week-long dedicated sprints for individual clients and not splitting your time up.
|
|
#
?
Dec 22, 2018 00:28
|
|
|
The Fool posted:I think one of the secondary points of that article is that even if you don't increase your rate, switching from hourly billing to weekly billing can increase your revenue and reduce your stress. Yeah. I already bill daily for one client, and for the other I've been doing small fixed bids but have actually just switched them to hourly. I might suggest pausing my day client and non-cancellable booking this other one on a weekly basis. If I shuffle things right then I should be able to get paid the same as I do now in 40 hour weeks rather than my current 60 hour weeks. I've read a few other articles and transcripts from that guy in the last few hours and I think it's worth noting that he's specifically courting SMEs rather than founders (which are who I often deal with) and that's something of a different kettle of fish. Founders are acutely aware of the small steps their money takes between them earning it and handing it to you, so they're very fixated on budget and value. I won't ever be able to increase my rate for my current main client without building out a larger company and bidding on whole projects, because it's the government and they have quite firm limits (but also always pay). Jaded Burnout fucked around with this message at 02:35 on Dec 22, 2018 |
|
#
?
Dec 22, 2018 02:31
|
|
|
So my company has an internal website which contains a bunch of links to various software that our non-IT users rely on. Earlier this year we set up a new data center and had to update all of our domain names. Whoever updated the internal site so that the links point to the new domains never checked this in to source control. I had to push an update to this site Monday, breaking the links because my version of the file from SVN was never updated, obviously. Didn't take long to fix it. But it caught the CTO's attention immediately, and he wasn't happy. I fixed it in under an hour on Monday when the problem was discovered. Today the CTO just sent a Meeting Invite to me, my boss, another manager, and the head of HR scheduled for Friday at lunch time.  Any idea how I can approach this meeting to protect myself? I don't feel like I did anything wrong. I did create a back up and the time stamp on the file that wasn't checked into SVN was at 5:50PM, which almost guarantees it was my boss who modified it earlier this year. I don't want to go into this meeting pointing fingers, but I don't think I did anything wrong. I grabbed an update from SVN, saw I had the latest - why would I think to manually diff my file against the live one first? That's the only way I could have prevented this. Sab669 fucked around with this message at 16:20 on Jan 2, 2019 |
|
#
?
Jan 2, 2019 16:09
|
|
|
If they’ve contacted HR it’s too late and you should be trying to learn your lesson. At best, they’re putting you on a performance improvement plan which is really another form of delayed firing. Source: I have fired several people, sometimes not because of my own desire as much as that of my superiors / clients.
|
|
#
?
Jan 2, 2019 16:21
|
|
|
I also don’t think you did anything wrong. I guess the best you can do is take in some evidence and operate on a “vague until finger pointing is necessary” approach
|
|
#
?
Jan 2, 2019 16:24
|
|
|
necrobobsledder posted:If they’ve contacted HR it’s too late and you should be trying to learn your lesson. At best, they’re putting you on a performance improvement plan which is really another form of delayed firing. Source: I have fired several people, sometimes not because of my own desire as much as that of my superiors / clients. In a lovely company, yes. They might be in a lovely company. In a decent company the question they should be asking is “why did you think this wouldn’t break production” to which the answer is “I assumed all changes were in source control” and the conclusion should be “everyone please stop making prod changes outside of source control”, or “everyone please make sure to check the exact version in prod for uncontrolled changes” if your cto is poo poo at his job
|
|
#
?
Jan 2, 2019 16:29
|
|
|
Regardless of what happens (unless the meeting is like "hooray you get a raise for exposing our broken process and making this a better company in the meantime!") find a new job. Any leadership that gets that upset about innocent mistakes caused by broken process (or literally, any mistake) that is utter poo poo and will never improve.
|
|
#
?
Jan 2, 2019 16:30
|
|
|
Sab669 posted:So my company has an internal website which contains a bunch of links to various software that our non-IT users rely on. Echoing what has been said by others: You didn't do anything wrong. Source control is supposed to be the single source of truth. There are multiple layers of failure here, and each layer of failure occurred before you were involved. 1. Changes should have been in source control 2. Developers should not be interacting with production systems 3. There should be a fully automated process of deploying changes, which depends on #1 and enables #2. The only thing I'd lay at your feet is that you broke #2. When acting in a role as a software developer, I absolutely refuse to touch production systems and would raise a huge stink if anyone asked me to do so. If the change was put into source control and was pushed through a standard automated deployment process, then you did absolutely nothing wrong. For your future reference, if rule #2 is broken on a regular basis and #3 doesn't exist or is only infrequently used, do not trust that what is present in a production system corresponds to what is in source control. New Yorp New Yorp fucked around with this message at 16:42 on Jan 2, 2019 |
|
#
?
Jan 2, 2019 16:39
|
|
|
I will concede I did break the site (again for less than an hour) while deploying another change a few months ago. So I get why the CTO might feel it necessary to schedule a meeting to say, "Listen you dumb gently caress: this site should not break for any reason" - but yea, I've just been writing everything down this morning: Date & Content of the back up on the live server Dates of my local files Dates of JIRA issues from earlier this year (assigned to my boss) naming the file that caused all of this. I did have an interview before Christmas, and another one tomorrow. Hopefully I can get the gently caress out of here, and make a lot more money in the process. Somehow I missed your response, New Yorp - yea I'm regularly asked to push aspx or cshtml files to production, both for internal & external products. For "functional changes" that would impact the JS or a DLL my boss does it during a scheduled maintenance period. Automated deployment? I loving wish. This company's SVN & deployment process is terrible and has been a complaint of mine since I started here. I've tried to build a tool to automate it, or at least make it easier, but never completed that project. Sab669 fucked around with this message at 16:48 on Jan 2, 2019 |
|
#
?
Jan 2, 2019 16:44
|
|
|
As for the meeting, emphasize that you regret the mistake, quickly resolved it, and are willing to help improve processes to ensure it won't happen again. Pointing fingers is usually seen as deflecting blame, even when justified. If you own up to the problem you did cause (breaking customer-facing links) and have a way to fix it (have everyone use the same source control and/or have a staging site for upcoming changes), it's much better optics than "so-and-so didn't use source control so it's not my fault". Agreed that calling HR in for what seems like a fairly low-stakes mistake* is a sign that you're not in a great place. Have there been several incidents like this? *Customer facing is usually bad news. But unless you're losing significant amounts of money every second they're down, a broken link is not that big of a deal.
|
|
#
?
Jan 2, 2019 16:44
|
|
|
You can say "the latest changes weren't in source control" without saying "because so-and-so didn't check them in". Talking about underlying root causes without having to name names is important. The process is broken, it isn't the fault of the person who didn't check in the files any more than it is your fault. All production builds should be built from source control, there should be no way to ever put something into production that isn't checked in. If your CTO is so incompetent that they can't see this then 
|
|
#
?
Jan 2, 2019 16:54
|
|
|
The way I would recommend writing this up (which is basically paraphrasing the Alphabet post-mortem template) is:
Notice that none of that involves blaming any individual. If something goes wrong, it's because the processes and automated tools are at fault, not the individuals. Of course, it is true that a person had to make a faulty decision for a problem to occur, but assigning blame to that person is bad for the company in the long-term: people who are afraid of making mistakes or otherwise feel insecure are less productive than people that are psychologically safe. In this case, your takeaway action items would be something like "modify our deployment tools to only accept deployments from a clean SVN client", and possibly "modify deployment tools to provide a list of changes being made in a deployment." Bring that with you to the meeting and do your best to focus the conversation on the document, not on the people. Make it clear that you want to prevent accidents. Do not accept blame for the accident (while yes, recognizing that your actions are the most proximate cause).
|
|
#
?
Jan 2, 2019 16:56
|
|
|
And remember you are a skilled developer, so any time people want to brow-beat you into anything, ask if they plan to fire you. If not, why is HR here? If yes, can we discuss terms of separation?
|
|
#
?
Jan 2, 2019 17:20
|
|
|
Jaded Burnout posted:In a decent company the question they should be asking is “why did you think this wouldn’t break production” to which the answer is “I assumed all changes were in source control” and the conclusion should be “everyone please stop making prod changes outside of source control”, or “everyone please make sure to check the exact version in prod for uncontrolled changes” if your cto is poo poo at his job Not disagreeing in fault / blame but bringing in HR is already at the very minimum a formal disciplinary action on record. Sucks but nobody invites HR for fun and games exactly. I took ownership (and noted that the problems were well known and all documented corrective actions were blocked left and right in JIRA with a long history of attempts to fix or mitigate) for processes that were this horribly broken instead of throwing my direct reports under the bus like these “leaders.” Complete cowardice. Sounds about right for a company still using SVN though - it’s a sort of smell to me. If I get real weird I can imagine that HR might be getting involved to act as a third party witness to help ensure impartiality or something else, which also is indication IMO of a lovely company.
|
|
#
?
Jan 2, 2019 17:20
|
|
|
Also lol at a company larger than 8 letting developers directly push to prod without any oversight whatsoever whether it’s from a code repo or not.
|
|
#
?
Jan 2, 2019 17:25
|
|
|
Keetron posted:And remember you are a skilled developer, so any time people want to brow-beat you into anything, ask if they plan to fire you. If not, why is HR here? If yes, can we discuss terms of separation? This seems unnecessarily combative. Even if they said "no" this time, it's on their mind for the next time something happens...if you want to quit your job, just resign.
|
|
#
?
Jan 2, 2019 17:26
|
|
|
necrobobsledder posted:Agreed, but why would HR be involved in any of this unless personnel action is being taken? I don’t bring in my CFO during a code review. Perhaps it's wishful thinking on my part. But it doesn't *necessarily* indicate they're fired. Could be they're responsible for training and incident reports for all we know.
|
|
#
?
Jan 2, 2019 17:45
|
|
|
FWIW, the email for the meeting was titled "<website> cleanup" and the body simply said "quick review of the <website> site" Which sounds innocuous, but... It's going to be a long week and I'm not going to be able to stop thinking about this  I definitely don't think any sort of, "What are you going to do, fire me?" attitude is the right approach. They could. There's 1 other developer who used to work on my main project, and we pay an Indian software farm for projects too big for us - so the company could fall back on those guys if they're understaffed.
|
|
#
?
Jan 2, 2019 17:51
|
|
|
If I were in the same situation and it turned out HR was there for innocuous reasons, I'd sit down with my boss (if I trusted them) one-on-one and tell them how unnecessarily stressful it is to schedule a meeting that looks like I'm getting fired. I had to make similar complaints to a boss I had because various people kept setting meetings for 4:00 on Fridays with titles like "Org update" that turned out to be announcing a promotion or a new hire, but everybody kept thinking, "Oh no we're all fired!" (because that happened once or twice, too). Speaking of which, today is the one-year anniversary of my current job and the two-year-minus-one-day anniversary of losing the above job!
|
|
#
?
Jan 2, 2019 18:19
|
|
|
Talk to your boss before Friday, like, today. But it might not matter. With HR scheduled to be there, you may not have a job by the end. Brush up on your state's unemployment laws, and don't sign away your right to collect unemployment.
|
|
#
?
Jan 2, 2019 18:23
|
|
|
TooMuchAbstraction posted:Alphabet post-mortem template This is similar to the Amazon root cause of error analysis template.
|
|
#
?
Jan 2, 2019 18:38
|
|
|
CPColin posted:If I were in the same situation and it turned out HR was there for innocuous reasons, I'd sit down with my boss (if I trusted them) one-on-one and tell them how unnecessarily stressful it is to schedule a meeting that looks like I'm getting fired. I had to make similar complaints to a boss I had because various people kept setting meetings for 4:00 on Fridays with titles like "Org update" that turned out to be announcing a promotion or a new hire, but everybody kept thinking, "Oh no we're all fired!" That said, CPColin posted:(because that happened once or twice, too). return0 posted:This is similar to the Amazon root cause of error analysis template.
|
|
#
?
Jan 2, 2019 19:34
|
|
|
JawnV6 posted:Once again, goog and amazon didn't invent the blameless postmortem whole cloth. Yeah, I certainly didn't mean to imply that this was anything particularly novel; I was just providing a source. I dearly hope that most large tech companies have something similar, wherever they learned it from.
|
|
#
?
Jan 2, 2019 19:42
|
|
|
|
| # ? May 27, 2024 08:28 |
|
|
TooMuchAbstraction posted:Notice that none of that involves blaming any individual. If something goes wrong, it's because the processes and automated tools are at fault, not the individuals. - There's no consequences for cowboy behavior. If the real root cause was "I was lazy & careless, #yolo", then no amount of process/tooling changes will change that attitude, only mitigate it. - There was rarely incentive to act on the follow-ups. Everyone goes to the post-mortem meeting, they identify the root causes, they make tickets to fix the causes, and get the warm fuzzy feeling that progress is made... and then those tickets are de-prioritized and never get acted on, because "that outage was a one in a million chance", or they're understaffed, or it's too much effort to Fix It The Right Way.
|
|
#
?
Jan 2, 2019 19:53
|
|
