|
We have some high level product manager-ish guy (I've been so far unable to determine what his job actually is) who literally rolls his eyes when developers ask for use cases. He thinks we're trying to dodge work or something. Which I guess we are, in the sense that we don't want to spend time and effor to build the wrong thing, but I guess I didn't pay enough attention in my mind-reading class in college.
|
#
?
Mar 9, 2019 17:48
|
|
|
|
| # ? May 12, 2024 00:50 |
|
|
raminasi posted:We have some high level product manager-ish guy (I've been so far unable to determine what his job actually is) who literally rolls his eyes when developers ask for use cases. He thinks we're trying to dodge work or something. Which I guess we are, in the sense that we don't want to spend time and effor to build the wrong thing, but I guess I didn't pay enough attention in my mind-reading class in college.
|
|
#
?
Mar 9, 2019 17:58
|
|
|
agile consists in giving real actual power to developers and them being responsible with it that's a durable thing that's not susceptible to no true scotsmanning rule of thumb, therefore: if management starts it, lol go your chances of doing agile, most of the time the lean guy, taiichi ohno, taught the folks doing lean manufacturing that even the fuckin janitor can stop the line, if they find a defect. real power with real responsibility bob dobbs is dead fucked around with this message at 18:09 on Mar 9, 2019 |
|
#
?
Mar 9, 2019 18:06
|
|
|
Hughlander, Volmarias, Doom Mathematic, ultrafilter posted:Good stuff Thanks guys I'm going to share these with my co-workers and we can all have a laugh. One of them also made the suggestion that we add a :passion: custom emote to Slack. I'm not planning on actually doing anything terribly confrontational (except for the resignation one, which I'm currently working towards for other reasons), I just wanted to vent a little and give yall an opportunity to have a bit of fun. The good news about all this is that this was not some official edict and my actual boss doesn't agree with the CEO about this and doesn't plan on introducing clock-watching to our development methodology.
|
|
#
?
Mar 10, 2019 02:34
|
|
|
Cross posting, Are there any good coding boot camps folks are able to recommend? Hackbrightacademy looks awesome but I'm not a girl nor am I in San Francisco. 
|
|
#
?
Mar 10, 2019 04:26
|
|
|
I don't have data to back this up, but my impression so far is that those are designed primarily to separate people from their money.
|
|
#
?
Mar 10, 2019 19:12
|
|
|
If you're actually talented and interested in tech but didn't have the means to do a 4 year degree, they're not a bad choice. I've heard success stories from them, including people I know. The caveat is that if you don't "get" programming they won't really do anything and you're going to just fail out, but they can be a great "foot in the door", especially if getting past the "beep bop must have education" HR screening software is all you need.
|
|
#
?
Mar 10, 2019 21:11
|
|
|
With the current job market, it seems to be a good way to career change for a pay bump if it interests you. It surely helps to already have a four year degree in something to meet the minimum requirements.
|
|
#
?
Mar 10, 2019 22:17
|
|
|
https://twitter.com/ReinH/status/1104199331228266497
|
|
#
?
Mar 10, 2019 22:26
|
|
|
chutwig posted:The CTO at my previous company decided that an effective motivational tactic was to e-mail a picture of empty dev desks to the developer distribution list, asking them if they thought that [COMPETITOR'S NAME HERE]'s developers didn't come in until 10 AM (the answer, without even knowing the company, is yes). He decided to do this on a day when NYC received like 2 inches of rain and half the subway system was shut down, so most people couldn't even make it to the office anyway. For most people, this is when he went from being just annoying to actively nefarious, and people deciding they were tired of this lovely company started to snowball soon afterward. I found out later he had tried to use the same tactic at his last company, where I assume it went over about as well. LOL when the rear end in a top hat in online videogames who tries to shame his teams into doing what he wants becomes a CTO.
|
|
#
?
Mar 11, 2019 02:21
|
|
|
I’m already in IT and can write a few dozens lines in Powershell but would like to take it far beyond if that makes sense.
|
|
#
?
Mar 11, 2019 06:10
|
|
|
Got a newly transferred senior developer who can't figure out what "hey if this value is null, then return null immediately" means in a code review. I haven't seen his updated pull request but my coworker texted me to let me know, that two days later, he still hasn't got it. I refuse to believe that it's ignorance and I don't know what the gently caress to do.
|
|
#
?
Mar 11, 2019 23:27
|
|
|
Rubellavator posted:Got a newly transferred senior developer who can't figure out what "hey if this value is null, then return null immediately" means in a code review. I haven't seen his updated pull request but my coworker texted me to let me know, that two days later, he still hasn't got it. I refuse to believe that it's ignorance and I don't know what the gently caress to do. Either returning null immediately isn't the right thing to do, and he's fighting for that, or he's failed upwards. You know which one is more likely.
|
|
#
?
Mar 11, 2019 23:33
|
|
|
Tab8715 posted:I’m already in IT and can write a few dozens lines in Powershell but would like to take it far beyond if that makes sense. Try to work on upping your Powershell game on your own. This will give you a few advantages before looking at bootcamps (and spending a ton of money): - You can figure out if you actually enjoy the work of coding outside of a bootcamp environment (bootcamps tend to be very rah rah and geared towards helping beginners, actual coding jobs are less so) - You will collect online resources that will help you get more out of the bootcamp - Developing Powershell scripts for a public Github will put you ahead of bootcamp applicants when applying for jobs. Bootcamp projects tend to be very recognizable and some interviewers don't think they show too much of an individual's ability, because so much help was available from coaches. To get better at coding, I suggest making a list of scripts that would help you at your job. Then, pick the one that seems easiest and build it.
|
|
#
?
Mar 11, 2019 23:50
|
|
|
I recently had to explain to a senior dev why he couldn't copy the -d '{json...}' argument from a curl command and stick it on the end of the URL string in a Javascript request
|
|
#
?
Mar 11, 2019 23:53
|
|
|
I had to explain to a senior dev (expert in security, well an expert in everything really) how https works and why a 3rd party looking at the traffic would not be able to know exactly what URL you have requested from a server, despite the browser displaying said URL at the top in the address bar.
|
|
#
?
Mar 12, 2019 01:38
|
|
|
Volguus posted:I had to explain to a senior dev (expert in security, well an expert in everything really) how https works and why a 3rd party looking at the traffic would not be able to know exactly what URL you have requested from a server, despite the browser displaying said URL at the top in the address bar.
|
|
#
?
Mar 12, 2019 03:41
|
|
|
Vulture Culture posted:They could if it was being accessed through a proxy, but corp environments have more effective ways to MITM an asset Oh, it wasn't that advanced. We didn't get at the ways corporate IT can spy on your TLS traffic. Which are all fine and dandy. For now we were only at the "malicious 3rd party" chapter.
|
|
#
?
Mar 12, 2019 06:22
|
|
|
Rubellavator posted:Got a newly transferred senior developer who can't figure out what "hey if this value is null, then return null immediately" means in a code review. I haven't seen his updated pull request but my coworker texted me to let me know, that two days later, he still hasn't got it. I refuse to believe that it's ignorance and I don't know what the gently caress to do. A similar experience I had was when the company I then worked at hired someone as a senior dev/team lead and assigned her to my dev team without even consulting with us. The wrong questions were asked at the interview, it turned out. She didn't understand basic coding practices, and she didn't improve over time. But she was very good at arguing. When we asked some more details of her skills, turned out that before us, she worked at some company where the software team was, according to her description, like 90% fulltime architects and 10% developers. All she did there was sit in highover architecture discussions all day. For some idiotic reason my manager there trusted me more than my more experienced team mates so it took me to speak up to management before they did anything about it (they were considering giving her another position within the company). And then I left that company for greener pastures myself.
|
|
#
?
Mar 12, 2019 08:05
|
|
|
The sad fact is that 'Senior' should be read to mean little more than 'Has worked around software for a long time' without any intrinsic definitions around competance or knowledge.
|
|
#
?
Mar 12, 2019 10:50
|
|
|
Just like senior citizen.
|
|
#
?
Mar 12, 2019 13:00
|
|
|
Ither posted:Just like senior citizen. Oh my god, that is perfect.
|
|
#
?
Mar 12, 2019 14:15
|
|
|
I keep getting referred to as a Senior software engineer because I am 41, not because I have about 3 years experience as a dev. Of course, the years before software engineer count for something but I would not sell myself as a Sr, simply because I often have no clue what I am doing. This became very evident now that a serious Sr (15+ years experience ) joined and he comes up with great solutions I never heard of.
|
|
#
?
Mar 12, 2019 16:17
|
|
|
In my experience senior developers tend to act like they know poo poo, but don't concede when they don't. I've worked longer at this company than most of my peers, and they are always astonished to figure out how much I know about the platform. The people who ask me questions are new devs, the people who I always make comments on PRs are senior devs. They usually fight it and I'm wrong sometimes, but most of the time an architect pipes up and backs me up, which shuts them up. Granted, I also have reservations about how they vet their candidates at this company, so it's not really indicative of senior developers in the Denver area.
|
|
#
?
Mar 12, 2019 16:17
|
|
|
Started a new job last year at one of the biggest "software factories" in my country (this is my fourth company as a software dev), and somehow, out of all the places I worked, for the first time, the team I work with actually feels agile: * No scrum or similar bullshit * No deadlines * When I'm asked to estimate something, I can either respond with either "Not much work left" or "A lot of work left" and that's fine (no hours or story points or whatever) * When I start work on a feature, I'm immediately paired up with someone who will actually be using that feature * We have a great deployment pipeline, code reviews, actually smart and passionate developers on the team (sorry if this sounds bad but I feel like this is another first for me) * Bonus: actually get to work on interesting problems, like writing automation software for orchestrating tens of thousands of virtual machines Does this mean I can never change jobs again? Feels like I've won the lottery. Edit for some more context: From what I can tell, my team is quite unique in this company. It seems that the majority of other teams are micromanaged to hell and don't really work efficiently or follow best practices at all. I'm still in disbelief at how well my team works despite the rest of the company being completely different. sunaurus fucked around with this message at 16:42 on Mar 12, 2019 |
|
#
?
Mar 12, 2019 16:20
|
|
|
Also, speaking of idiots at my job, the one QA guy on my team is still dense as a rock. We are removing COM components from a clients' custom WPF screen (they pay us to do custom screens sometimes). Good news - they were just dangling references from the .csproj, so we remove it, say you just have to pop open the custom screen on the desktop client, and if it loads, testing is complete. What does our QA do? Finds two other open bugs on the screen, which are assigned to other teams, and starts bitching that those things are still not working. He also found another bug in our web client and states that needs to be fixed as well. Never listens to the developers and just wants to sit and scream, it seems like. What's the point of having developers tell QA what changed and what to test if they don't loving follow our directions?
|
|
#
?
Mar 12, 2019 16:42
|
|
|
The worst is when you spend several weeks pounding that concept into a QA person and then they actually find a serious bug in something you said shouldn't've changed and their timewasting is instantly validated for another couple months until you hammer it out of them again.
|
|
#
?
Mar 12, 2019 16:50
|
|
|
Having similar QA woes with our massive overhaul of the discounts system. What originally started as an ask to make discounts only work in a single country, selected upon creation, turned into rewriting the entire system because it was so unbelievably stupidly written that it was not actually possible to do that (we had distinctions between two separate models, which we called "old discounts" and "new discounts", and also each area of the site and type of product checkout, depending on phase of treatment, did things a completely different way). It was actually faster to just rewrite everything and gut all usage than it was to wrestle with the existing crap. Anyway, it's finally done, and QA gets their mitts on it.... First, every bug was duplicated by default, because, since they were testing the original story use-cases (i.e. per-country discount functionality), anything that had a bug would get one for a US discount, one for using a Canadian discount. We eventually gave up trying to explain to them that this is literally the same bug and you just triggered it twice and it has absolutely nothing to do with country-specific work; in fact, they actually confirmed that feature was working just fine since they triggered the identical bug both ways! But then they ran into some overlap with tickets in progress on other teams who were working on language stuff (I loving warned them day 1 of the Canada push we had to provide French if we offered service in Quebec, I'd been through a Canadian internationalization push at a previous job, but did anyone loving listen? NOPE! Now we're doing double the work to go back and add that in). Cue nonstop "bugs" which are really "we were testing poo poo that literally has not been integrated yet because another goddamn team is working on that". I really wish we would stop contracting with a group in India to do overnight regression poo poo. I have great relationships with some of those guys, but the language barrier and just cultural differences in how they approach the work are incredibly difficult sometimes, it's impossible to get them to go beyond "I executed this test scenario and the precise outcome expected did not happen, therefore write 4 bug tickets and stop testing until that is fixed, even though no other test scenarios depend upon this functionality". It's been an ongoing battle that's really slowing us down when this is already behind because the discount system was so utterly hosed to begin with  But on the positive side, my code has had only THREE ACTUAL BUGS! One was a minor flaw in logic for our retail kits (I called the wrong service method once), and two typos. I'm pretty goddamn proud of that, considering it's a few thousand lines of code worth of work slammed out as quickly as possible, and I ended up taking over some work at the last minute from two others on my team who were dragging their feet.
|
|
#
?
Mar 12, 2019 16:59
|
|
|
CPColin posted:The worst is when you spend several weeks pounding that concept into a QA person and then they actually find a serious bug in something you said shouldn't've changed and their timewasting is instantly validated for another couple months until you hammer it out of them again. Especially when that bug was introduced over a year ago and they never noticed it until just then.
|
|
#
?
Mar 12, 2019 17:02
|
|
|
It's become habit to me to ask our QA's if they've tested on the core version QA box. Since we all have environments for our feature work, they think we introduced the bug - I have to force them to test in an environment without our changes to make them believe we didn't break it. The amount of duplicate bugs though... it's a good thing we moved into Azure DevOps and stopped self-hosting TFS.
|
|
#
?
Mar 12, 2019 17:10
|
|
|
BaronVonVaderham posted:
I see what is your problem here. And it is a) outsourcing and b) to India. Having worked as a local hire for an Indian outsourcer (hey, it was very good money), I can say that you guys are not measuring success with the same ruler. Your success is an application that meets business needs, their success (personal and business) is measured by testcases executed and bugs found. Seriously, being able to log the same bug twice because of language is like free lunch to them!
|
|
#
?
Mar 12, 2019 20:31
|
|
|
Someone over in the BFC thread just characterized these people perfectly: "human checklists." They don't have the ability, and oftentimes the permission, to critically think about anything, and just go down the list no matter how much sense it doesn't make. Got a showstopper bug 5% of the way through a program's workflow? They'll happily test every case past that bug, and every case will fail with the same error message because they literally couldn't proceed far enough in the workflow to get to the test case.
|
|
#
?
Mar 12, 2019 21:30
|
|
|
Outsourced QA is a symptom of the belief that you can buy a regression test suite and thereby free up developers to write features instead, as though there was a difference between writing tests and writing implementation code.
|
|
#
?
Mar 12, 2019 21:46
|
|
|
It sends a message to everyone that more features are important than how well they’re implemented or tested. All the easy to test stuff tends to not break, all the hard stuff is almost never caught by even developers let alone QA. The signal to non-technical people of investing in QA is “we’re trying!”
|
|
#
?
Mar 12, 2019 22:12
|
|
|
Che Delilas posted:Someone over in the BFC thread just characterized these people perfectly: "human checklists." They don't have the ability, and oftentimes the permission, to critically think about anything, and just go down the list no matter how much sense it doesn't make. Got a showstopper bug 5% of the way through a program's workflow? They'll happily test every case past that bug, and every case will fail with the same error message because they literally couldn't proceed far enough in the workflow to get to the test case. It seems like every QA person has to go through this stage, at least at first. Pipelines are complicated, and dependencies often aren't super clear. We've been building a much bigger QA team where I work, and we often get bug reports from newer QA people that say "Feature X doesn't work on test environment A", and we take a look, and the environment isn't configured to run X, or is configured to run X with some different options that make it behave differently. Seems like it's just part of onboarding.
|
|
#
?
Mar 12, 2019 23:12
|
|
|
sunaurus posted:A happy story Good places do exist. I'm in a similar situation where the level of product and engineering culture, tooling, and support are fantastic and there's always a focus on improving. It's to the level that our less experienced developers don't appreciate how lucky they are to have the autonomy and productivity we do. I'm trying to work out if there's a good repeatable way to find places like this without just word of mouth. This one I found nearly four years ago by searching job listings for a specific automated deployment system because I figured if they were using that they must be fairly advanced. I'm not sure what I'd use these days, I think a lot of the management/product side of the culture matters a lot but that's much harder to read from the outside.
|
|
#
?
Mar 13, 2019 00:29
|
|
|
Destroyenator posted:Good places do exist. I'm in a similar situation where the level of product and engineering culture, tooling, and support are fantastic and there's always a focus on improving. It's to the level that our less experienced developers don't appreciate how lucky they are to have the autonomy and productivity we do. These days my filter is if they have testers or not and if not, if the devs are expected to build the testsuites and maintain the application in production. If that is the case, a place has this build in incentive to create stable software. Also, everything has a tendency to be automated and deployed multiple times per day. The absence of testers moves the responsibility for quality back to the devs and unless management is being assholes (pushing for features over devs complains about tech debt, ask about this in interviews), it is a pretty good indicator. This also leads to a slight shift in desirable skills, stuff like jenkins, AWS, test pyramid automation stuff and smart logging becomes more valuable during interviews.
|
|
#
?
Mar 13, 2019 07:29
|
|
|
There was this documentary I remember from years ago about some Swedish woman that tries to communicate with moose. At one point she goes out into a stream, hold antlers over her head, and tries to grunt at one. In a panic, it pisses into the middle of the river. That is what I feel like when I'm trying to explain packaging and releasing software to a bunch of electrical engineers with "software engineer" comic sans painted over their job titles. sunaurus posted:Started a new job last year at one of the biggest "software factories" in my country (this is my fourth company as a software dev), and somehow, out of all the places I worked, for the first time, the team I work with actually feels agile: When that manager goes, you're going to have to follow them.
|
|
#
?
Mar 14, 2019 07:32
|
|
|
Protocol7 posted:Also, speaking of idiots at my job, the one QA guy on my team is still dense as a rock. A developer shouldn't tell a QA what to test. They should suggest what to test. The QA should then take that recommendation, and with their own knowledge of the system, come up with a comprehensive test plan that exercises the feature and does regression. If they find a new issue, and it's caused by the ticket that's currently in testing, kick it back to the developer. If they find a new issues, and it's not caused by the current ticket, create a new one. Put that on the backlog to be prioritized. If they find a known issue, they should add their comments to the already existing ticket. CPColin posted:The worst is when you spend several weeks pounding that concept into a QA person and then they actually find a serious bug in something you said shouldn't've changed and their timewasting is instantly validated for another couple months until you hammer it out of them again. This is actually a good thing because it means the QA is thinking instead of following orders. You should buy them a drink. Ither fucked around with this message at 14:28 on Mar 14, 2019 |
|
#
?
Mar 14, 2019 14:24
|
|
|
|
| # ? May 12, 2024 00:50 |
|
|
Ither posted:This is actually a good thing because it means the QA is thinking instead of following orders. Round after round of this particular person discovering bugs that existed in Production and were already filed proved that they were, in fact, not thinking. Also the tendency to file a bug where the description was "I think X should act like Y instead." To clarify, I agree with you, on principle, just not in the context of this former coworker of mine.
|
|
#
?
Mar 14, 2019 15:09
|
|