|
do a small project, use that to figure out stuff, use project to get into a bootcamp with selective admit criteria, i've seen that work out actually good
|
#
?
May 30, 2020 07:28
|
|
|
|
| # ? May 26, 2024 22:15 |
|
|
So, I'm not comfortable moving right now because of the coronavirus, but would it make sense to apply for jobs in the city or out of state that are doing remote work now, and then move later when we get the all-clear?
|
|
#
?
May 31, 2020 16:14
|
|
|
Why not? Alternatively, why not ask to stay remote afterwards (unless you WANT to move, of course). On a related note, I'm just wrapping up a code challenge for a full-time remote job, because gently caress going back into an office ever again. But... the challenge is in asp.net web forms and for at least some period of the job I'd be maintaining their legacy code base, which positively does not excite me. Part of me says, "Well don't jump at the first offer you get" but then the other part of me says "Who gives a poo poo, if they'll pay me more and let me stay home then do I really care what tech I work on?" I'm interested in the van life thing in a few years, so full time remote work is very intriguing to me but I'm always inconfident in my ability to land jobs 
Sab669 fucked around with this message at 17:59 on May 31, 2020 |
|
#
?
May 31, 2020 17:41
|
|
|
Sab669 posted:But... the challenge is in asp.net web forms and for at least some period of the job I'd be maintaining their legacy code base, which positively does not excite me. Part of me says, "Well don't jump at the first offer you get" but then the other part of me says "Who gives a poo poo, if they'll pay me more and let me stay home then do I really care what tech I work on?" i often have to work in almost 20-year-old php code at work despite being hired to do react front-end development. job pays well and it's fully remote. for a very long time this frustrated me, but eventually i stopped caring as much and now it doesn't affect me as much. that said, you will have more opportunities and maybe one that's also a bit more intellectually interesting. always keep looking!
|
|
#
?
May 31, 2020 17:47
|
|
|
Sab669 posted:On a related note, I'm just wrapping up a code challenge for a full-time remote job, because gently caress going back into an office ever again. But... the challenge is in asp.net web forms and for at least some period of the job I'd be maintaining their legacy code base, which positively does not excite me. Part of me says, "Well don't jump at the first offer you get" but then the other part of me says "Who gives a poo poo, if they'll pay me more and let me stay home then do I really care what tech I work on?" As I get older, I have started preferring "legacy" projects to new product development. Legacy products worked, and shipped, and have customers, and generally the requirements and technology choices are going to be clearer than with a new product. New products generally involve some combination of a) unclear requirements, b) new technologies with differing maturity levels, c) harsh deadlines, d) much higher chance of failure. I'm also not as worried about stagnation because I have found if anything, that newer programming stacks are generally becoming progressively easier to use than the older ones, and that it was not difficult to pick up the new stuff when I needed to use it, and sometimes it can even be introduced into a legacy code base when it makes sense.
|
|
#
?
May 31, 2020 18:04
|
|
|
Interesting considerations; a complete lack of requirements is definitely a complaint at my current job where it's all new features / alpha software 
|
|
#
?
May 31, 2020 18:14
|
|
|
Sab669 posted:On a related note, I'm just wrapping up a code challenge for a full-time remote job, because gently caress going back into an office ever again. But... the challenge is in asp.net web forms and for at least some period of the job I'd be maintaining their legacy code base, which positively does not excite me. Part of me says, "Well don't jump at the first offer you get" but then the other part of me says "Who gives a poo poo, if they'll pay me more and let me stay home then do I really care what tech I work on?"
|
|
#
?
May 31, 2020 23:50
|
|
|
What about legacy monoliths that want to modernize, but keep changing tech stacks every 6 months so you can't ever plan anything because it's always in transition to something better 
|
|
#
?
Jun 1, 2020 01:21
|
|
|
kloa posted:What about legacy monoliths that want to modernize, but keep changing tech stacks every 6 months so you can't ever plan anything because it's always in transition to something better Every so often a "new" technology comes out that's actually unilaterally better than what came before, and sometimes transitioning to that costs less than continuing to maintain new code. I've seen such a thing happen once or twice in a career. At least technology refreshes generally have actual requirements and customers. Some modern shops jump from technology to technology like a butterfly on crack. I have a pet theory about this - I think the fault lies in the modern system of western education. One of the ways children are motivated to learn is that they are encouraged to memorize useful material and regurgitate it on tests, and cramming more stuff and having a wider field of knowledge is rewarded through dopamine rewards of higher numbers on tests. In order to use a new product or technology, it often may require considerable time and testing in order to actually implement properly. The problem becomes that the person who is tasked with evaluating the technology will start to become invested in the adoption of new technology, as the learning of the new technology feels similar to the school days learning of new material, and in the process of evaluating the technology will become an advocate. It takes a special kind of discipline to learn how to do something while being skeptical of the value of what you're learning -- and most people don't have that discipline and will just recommend technologies that they've newly learned if they aren't obviously inappropriate for the problem domain.
|
|
#
?
Jun 1, 2020 01:48
|
|
|
I think it's less about education and more about the hiring process. It's easier to get an interview if you have the latest and greatest technologies on your resume, so people are looking for opportunities to get that experience.
|
|
#
?
Jun 1, 2020 02:57
|
|
|
To me it’s just that working on legacy poo poo really, really sucks, so it’s easy to think “if we could just overhaul it the lovely parts would be gone and I’d love my job again instead of hating every soul sucking moment of getting blocked and waylaid by 20 year old decisions.”
|
|
#
?
Jun 1, 2020 15:44
|
|
|
I also think it's a bit of a shiny-nut scenario. Engineers that enjoy the work are always looking for the next latest and greatest because new toys are fun. It's fine when you're at a greenfield shop. Elsewhere you have to be very, very, very sure that you want to make a switch, otherwise you wind up with a PITA patchwork. I say this as a Eng Manager for a team who just decided (after almost a month of deliberation) to switch from React to Vue for new dev work >_<
|
|
#
?
Jun 1, 2020 15:46
|
|
|
Eggnogium posted:To me it’s just that working on legacy poo poo really, really sucks, so it’s easy to think “if we could just overhaul it the lovely parts would be gone and I’d love my job again instead of hating every soul sucking moment of getting blocked and waylaid by 20 year old decisions.” And just so we're clear, it never, ever works out this way.
|
|
#
?
Jun 1, 2020 16:38
|
|
|
Well I think it can if you can find the right scoped pieces but yeah, mostly it’s the cry of the naive (I was once as naive).
|
|
#
?
Jun 1, 2020 16:43
|
|
|
kayakyakr posted:... Lol. We just did the exact opposite. Even though our main product is built on laravel, which defaults to vue of the box.
|
|
#
?
Jun 1, 2020 16:43
|
|
|
i once saw it work but that was after a near total firing of the technical management and replacement by competent peeps the ceo knew programs reflect social organization
|
|
#
?
Jun 1, 2020 16:44
|
|
|
bob dobbs is dead posted:programs reflect social organization https://en.wikipedia.org/wiki/Conway%27s_law
|
|
#
?
Jun 1, 2020 17:23
|
|
|
So what does this say about my org, where our overarching system is a distributed monolith of services mostly eschewing simple request-response interfaces in favor of shoehorning cumbersome Kafka interfaces in every possible orifice, bizarre Rube Goldberg-style mechanisms, and ball of mud shared dependencies where every app has every library has every other library and they all can't wait to break if you fart in the wrong direction? 
|
|
#
?
Jun 1, 2020 22:12
|
|
|
conways law is about communication. biggest strong example is no backdoors in amazon, you always gotta make stuff that can be productized later, which allowed them to basically whack out aws. but that was an offshoot of a turbo memo based culture where everyone writes and reads and communicates all formal like so your company like most others is composed of a buncho whackjobs fuckin around lol
|
|
#
?
Jun 1, 2020 22:33
|
|
|
bob dobbs is dead posted:i once saw it work but that was after a near total firing of the technical management and replacement by competent peeps the ceo knew My company pulled it off once, kinda. It required a complete C-level turnover, a competent CTO, and about 3 years. There's still some lingering load bearing legacy stuff though.
|
|
#
?
Jun 2, 2020 13:45
|
|
|
Arrrgh. Recruiter sprang on me that the job was looking for 1+ years using Angular. This was not in the job description. But Angular is just an MVC framework right? So I emailed them back that I've used MVC frameworks before. Waiting to hear back from them.
|
|
#
?
Jun 5, 2020 00:03
|
|
|
SardonicTyrant posted:Arrrgh. Recruiter sprang on me that the job was looking for 1+ years using Angular. This was not in the job description. But Angular is just an MVC framework right? So I emailed them back that I've used MVC frameworks before. Waiting to hear back from them. Angular.js (a.k.a. Angular 1.x) is MVC-based, and is essentially a dead product. Angular (a.k.a. Angular 2+) is component based, and is much more modern and is Typescript-native and also heavily built around rxjs. The worst thing Google did was maintain the Angular name when completely rewriting the framework. Angular 2+ is almost nothing like Angular 1. They created a whole mess of confusion, and did themselves a disservice by conflating the two, especially since Angular.js left a bad taste in a lot of folks' mouths. I worked in Angular for a couple of years (from 2.x to 5.x) and IMO it's actually quite nice once you learn the ropes. As a full-featured, opinionated framework it works well in an enterprise environment with multiple teams because it enforces a certain amount of consistency in patterns, and also Typescript fuckin' owns bones compared to vanilla JS. I work in React now, and there's a number of things I miss about Angular. The piecemeal nature of React apps can be maddening. But in a lot of ways they are more similar than dissimilar, conceptually. If you've used React (or even Vue), Angular is not a huge stretch to pick up rather quickly. Guinness fucked around with this message at 00:17 on Jun 5, 2020 |
|
#
?
Jun 5, 2020 00:09
|
|
|
Well, hopefully they don't know that.
|
|
#
?
Jun 5, 2020 00:15
|
|
|
Guinness posted:especially since Angular.js left a bad taste in a lot of folks' mouths. Really? Because I was extremely excited when I first tried Angular, back in 2012 or so. It ran circles around the libraries that existed at the time. It was better in every way imaginable. Angular 2, when it came out, it was at most a meh, with nothing really to show for it at the time, why was it better than 1.x and why should one change overnight. Nowadays, with Typescript, yeah it's better, but mainly because of Typescript itself. Same poo poo but a different colour.
|
|
#
?
Jun 5, 2020 02:46
|
|
|
I did one project in Angular 1 and really liked it, haven't tried any version since.
|
|
#
?
Jun 5, 2020 04:56
|
|
|
Most of Angular 1, like the entire dependency injection system, exists almost entirely to work around the limitations of the 'use Gulp to concatenate JS files together' pre-Webpack/pre-module approach. The rest is a watcher-based render engine that has incredibly terrible performance as soon as you have an even moderately complex page.
|
|
#
?
Jun 5, 2020 05:14
|
|
|
I've been working with Angular 7 for the past year and it's ok. Observables are still kicking my rear end though.
|
|
#
?
Jun 5, 2020 12:30
|
|
|
Doghouse posted:I've been working with Angular 7 for the past year and it's ok. Observables are still kicking my rear end though. This is the Promise that never ends Yes, it goes on and on my friends Some people, started piping it not knowing what it was But they'll continue mapping it forever just because
|
|
#
?
Jun 5, 2020 12:44
|
|
|
Roadie posted:Most of Angular 1, like the entire dependency injection system, exists almost entirely to work around the limitations of the 'use Gulp to concatenate JS files together' pre-Webpack/pre-module approach. The rest is a watcher-based render engine that has incredibly terrible performance as soon as you have an even moderately complex page. You can work around the terrible observer performance by using it a lot like React with a way worse templating language though!
|
|
#
?
Jun 5, 2020 15:03
|
|
|
I've managed to brow-beat the recruiter into setting up a phone interview next week. I get the feeling I still won't get the job, but I'm very proud of myself for not giving up when they started adding requirements not in the job description.
SardonicTyrant fucked around with this message at 20:32 on Jun 5, 2020 |
|
#
?
Jun 5, 2020 20:30
|
|
|
Well, just had my first employee quit since becoming a manager. Interesting reason: The mother-company closed the local office and hadn't yet announced if they were going to be in a new office or coworking space once covid goes away. She gave me a 1 week notice... I'm in quite the pickle. I'm not losing her budget, so backfilling is possible. Here's the dilemma: Mother-company is quite fond of offshore resources. I can see why: I can get 4.5 individuals from our contractor for the same price as our departing onshore dev. And some of them sure can put out a bunch of code. But they need so much oversight. You have to comb line by line through PR's to get them to fix basic stuff, and often the same stuff as on the last PR. So they add a huge amount of velocity, but also drag down the velocity of the onshore team. They also add a huge burden on our product team, who have to create entirely new initiatives in order to find more stuff that they're capable of doing. Most of the time we have them do the simple bugs and UI tweaks while the team handles complex bugs and feature work. But it's also a reaaaaally good time to be hiring, especially remote and would allow us to bring in someone with more experience in our new framework. Probably could find a developer shifted in our favor and have enough room to keep an offshore. No budget for recruiting. Onshore is also a lot harder to get rid of (if things get a little tight, they'll cut offshore in a heartbeat, but may just hold their breath to avoid layoffs). If we don't backfill, we may permanently lose a team member. What to do, what to do...
|
|
#
?
Jun 8, 2020 17:02
|
|
|
kayakyakr posted:Mother-company is quite fond of offshore resources. I can see why: I can get 4.5 individuals from our contractor for the same price as our departing onshore dev. 4.5 offshore devs will require 1 onshore manager/team-lead, whose full time job will be managing them.
|
|
#
?
Jun 8, 2020 17:14
|
|
|
lifg posted:4.5 offshore devs will require 1 onshore manager/team-lead, whose full time job will be managing them. In our case, we've been spreading that out on the team. It's hit me and our architect hardest. I was actually excited to have that contract ending so we could free ourselves up to focus on feature work. I'd estimate that they've added the equivalent of a 2 dev throughput (across 3 or 4 developers) while stealing away 1 dev's worth of time for oversight.
|
|
#
?
Jun 8, 2020 17:20
|
|
|
You end up with 1 dev total in the end, and you spend 1 onshore dev expense and 3-4 offshore dev expenses, which adds up to ~2 onshore dev salaries. Doesn't feel like efficient use of the budget, if I understood your math correctly.
|
|
#
?
Jun 8, 2020 17:59
|
|
|
Definitely go for a local hire. If your area is anything like mine, there are suddenly tons of good people who’ve been laid off or are looking to jump ship for something new/more stable. We’ve had a couple positions open since before the pandemic, and back then, we were having trouble filling them because applicants were too junior or weren’t up to snuff, but now we have our pick of high quality senior people. As for offshore developers, if the offshore team of 4.5 guys needs that much handling, the benefit of more developers kinda gets canceled out. One good local developer that doesn’t require constant micromanagement and hyper intensive code reviews seems like a better deal, honestly.
|
|
#
?
Jun 8, 2020 18:01
|
|
|
gbut posted:You end up with 1 dev total in the end, and you spend 1 onshore dev expense and 3-4 offshore dev expenses, which adds up to ~2 onshore dev salaries. Not to mention the team communication and morale, and overall additional frustration and exasperation of dealing with all the extra BS. If my software team started leaning on offshore resources, I'd start looking for the exit. I've been there before, not doing that again.
|
|
#
?
Jun 8, 2020 18:15
|
|
|
kayakyakr posted:I'd estimate that they've added the equivalent of a 2 dev throughput (across 3 or 4 developers) while stealing away 1 dev's worth of time for oversight. Developers are not atomic units. Overseeing remote developers can be a very stressful job which will increase the burnout rate of your local developers and could lead to more local turnover. The remote developers I've worked with also turned over frequently - they're human beings too, and they know they're getting tossed the poo poo work - so you stand a good chance of losing what little institutional knowledge can be formed. For an engineering manager who has other choices it's just not a good deal. e: beaten
|
|
#
?
Jun 8, 2020 18:19
|
|
|
kayakyakr posted:Well, just had my first employee quit since becoming a manager. Interesting reason: The mother-company closed the local office and hadn't yet announced if they were going to be in a new office or coworking space once covid goes away. She gave me a 1 week notice... You are going to find excellent developers locally whose only fault was that they were working in an industry that was vulnerable to a quarantine situation. Go local. The rest of this is going to sound harsh if you haven't heard it before. I'm trying to help you be better as a manager and a person, and if you take it at least to mind you're going to end up in charge of good people who trust you. People have pointed some of this out already but let me underline it because it's pretty gross: your posts indicate that you don't think of these people as people. You think of them as units of output. My earnest advice to you, if you care even the slightest bit about being a good manager, is to knock it the hell off. The first and easiest step is to stop using the word "resources" the way you're using it, because used that way it is insidiously dehumanizing, and behaviors like this infect your entire mindset. The fact that you acknowledge that there's a productivity overhead to having offshore developers is a point in your favor, so please also be aware that it tends to severely impacts your senior devs' morale (unless you hire offshore people that are worth a drat, and given you're talking about hiring them for 20% of a local's salary that doesn't seem likely). At the end of the day, a happy developer is more productive than one who's forced to do nothing interesting because they have to teach kindergarten all day. I know the last few posts have said the same thing. Take the fact that it keeps being repeated as a strong sign you should pay attention. Your company hesitates to get rid of local developers? GOOD. That alone should make your decision for you. Again, these are PEOPLE we're talking about, not interchangeable metal cogs; they have lives and needs and they're probably extremely concerned about how stable their career is going to be for the next few years. Maybe you shouldn't be making it easy to dump them the instant some executive decides they need a twentieth sports car this year. I don't know why that developer gave you 1 week's notice. If you treat your developers the way your posts suggest you might, you should probably count yourself lucky. Developers who trust and respect at least one of their managers typically don't mind giving a more typical notice. If your job is to manage engineers, and it sounds like it is, try to nurture them. Treat them like individuals, figure out what their goals and frustrations are (this is what 1 on 1s are really for, if you're doing them correctly), try to help them achieve the former and fix as much of the latter as you can. If you do that, again, they're going to trust you more and be more productive. If you think of people like objects with a dollar amount stapled to their heads, the people you're in charge of are going to detect that. They're going to punish you for it, make your job harder in a thousand little ways, and you aren't going to understand why because they won't trust you enough to tell you.
|
|
#
?
Jun 9, 2020 02:40
|
|
|
Che Delilas posted:The first and easiest step is to stop using the word "resources" the way you're using it, because used that way it is insidiously dehumanizing, and behaviors like this infect your entire mindset. This is extremely common in corporate settings, IME. Not that I'm endorsing it - I don't like it either, just pointing out that it's quite common jargon and doesn't necessarily indicate personal bias but rather a systemic one.
|
|
#
?
Jun 9, 2020 13:59
|
|
|
|
| # ? May 26, 2024 22:15 |
|
|
Munkeymon posted:This is extremely common in corporate settings, IME. Not that I'm endorsing it - I don't like it either, just pointing out that it's quite common jargon and doesn't necessarily indicate personal bias but rather a systemic one. All the more reason to point it out so this manager can start reevaluating their own mindset. "High velocity" offshore devs who need massive oversight seems like an oxymoron. Velocity is a measure of one thing - tickets closed, probably, but unless you have some very good metrics there is no guarantee that those tickets are never reopened / don't cause N bug reports to be filed / don't require reworking. The amount of oversight needed to keep them productive (finding stuff easy enough to do, reviewing PRs, etc) doesn't seem to be considered as part of this "high velocity", because by your own math, it seems they have average velocity at best. Don't forget that writing software is not something that really can be measured in terms of immediate code output. It is entirely possible that offshore devs are adding negative velocity to your team in the long run (and you should talk to your team about what they need, because it doesn't seem like that is factoring into your thinking at all). On the other hand, an experienced local member of your team with business context / institutional knowledge can increase velocity with good architecture decisions and a little bit of thinking ahead. One of my company's biggest errors was allowing an offshore team to develop a key product feature early on. That single feature had to be completely rewritten after trying to limp it along for several months with tons of bugfixes because the original architecture was so poor. Of course, by the time of the rewrite, there were already customers using it, and the rewrite took a massive amount of time longer than the original feature development, because it couldn't disrupt the customer experience at all. The usual argument is to not give an offshore team anything that important, but does that really add a lot of value at that point?
|
|
#
?
Jun 9, 2020 14:28
|
|
