> Pairing is probably better than two solo devs if both pairers can handle it. Man, am I the only one that absolutely detests pair programming? Not only do I find it socially awkward, it completely kills my productivity. Software development is often about building a very complex model in your head and then figuring out the changes that need to be made. Having to dedicate half of my mental bandwidth to handling socia…
Uncomfortable Truths in Software Engineering
291–300 of 400 posts
Re: Uncomfortable Truths in Software Engineering
#292My Own Addition: 14. Those who code for a living make good money. I have a lot of friends who went into various fields, and it seems relative to the number of buttons we press daily, anyone who works on software makes great money. We didn't spend a ton of $ to go to medical school and 3 years of residency. We didn't go to law school and take the bar. Most of us went to 4 years, or less, of school, and here we are mak…
To a large extent, it is their individual choices. They went in with their eyes wide open, knowing what the market is like. If you decided to pursue something like librarian studies without a concrete plan for income, then it is hardly the fault of society if you do not get a job. I have commented on this yesterday and I will post it here again. Not every job will change the world, but often those boring but well pay…
Re: Uncomfortable Truths in Software Engineering
#293Earlier quoted context omitted.
> Working as a software developer without a passion for coding is kind of like doing math homework every day for the rest of your life. I disagree. I coded for fun once, as a kid, and have never felt the need to do it again. If I never coded again, I wouldn't even notice because I my passions lie elsewhere. But working as a software developer is still tolerable because I'm just sitting at a desk, typing on a computer…
Are you above 35?
Re: Uncomfortable Truths in Software Engineering
#294Earlier quoted context omitted.
I'm unsure what you're trying to express in this reply. It seems we do agree in general viewpoint, just perhaps we have different ways of expressing that view. Discrimination definitely happens, but I have yet to see one example of "pretty open discrimination" that hasn't resulted in an all out PR disaster for the org involved ,your "Read the news" statement supports that. If discrimination were a common occurrence i…
My close friend interned at a small embedded devices company and was the only woman besides a part time HR employee. People made comments about the HR employee when she wasn't around. Is this "pretty open discrimination"? It certainly doesn't make the cut for news. But yes it's very uncomfortable to be the only woman in that situation, people wok look at you for approval for their comments.
Re: Uncomfortable Truths in Software Engineering
#295Re. 3 & 5: my theory is that a language with gradual typing, gradual error handling enforcement, and "gradual proving" that is seamlessly embedded in it (see e.g. the https://nim-lang.org/docs/drnim.html experiment) could hopefully actually work here. And as to dynamic typing, I found it useful when prototyping, to quickly PoC/MVP the "happy path" of an idea/design, and see if it is worth investing any bigger effort,…
Is that enso software related to the software launcher by Aza Raskin?
Re: Uncomfortable Truths in Software Engineering
#296Pair programming or mobbing are a huge waste of resources. I know that myself I can't actually get anything done unless I'm in control. The only use this sort of this could have is to train juniors or hand over projects.
Likely for some, but not all cases. Pair programming at my shop had a weird positive multiplier effect on velocity/delivery. It was optional and about half the team did it. Different folks work differently, we aren't all productive in the same ways.
Re: Uncomfortable Truths in Software Engineering
#297Earlier quoted context omitted.
Are you sure the current campaigns aren't effective? The demographics are indeed changing. I know causation correlation blah blah, but we're just speculating in this thread, supplying no data anyway.
The gender ratio is changing for the worse. In 1984, women made up something like 37% of CS students. Now it's under 20%. Reference: https://jaxenter.com/wp-content/uploads/2017/04/women-in-com...
Re: Uncomfortable Truths in Software Engineering
#298Earlier quoted context omitted.
> The demographics are indeed changing. The gender ratio isn't changing though. If anything it is becoming worse, it was decades ago that less women went into software engineering today. The only thin that changed is that now every company tries to put their women software engineers front and center, in their marketing material, to go speak at conferences etc. So it looks like there are more women, but there aren't.…
This page suggests otherwise (although the effect is slight): https://www.zippia.com/software-engineer-jobs/demographics/ Do you have other data?
> 2008 Male: 72.33% Female: 27.67%
> 2013 Male: 73.44% Female: 26.56%
> 2018 Male: 73.82%. Female: 26.18%
The year by year numbers are too noisy to really mean much. 2018 being 0.3% percentage points higher than 2016 doesn't say much.
Anyway, the main point is that the gender ratio isn't really improving. At best you can say that it has stagnated, rather than getting worse as it did a decade ago.
Re: Uncomfortable Truths in Software Engineering
#299> Pairing is probably better than two solo devs if both pairers can handle it. Man, am I the only one that absolutely detests pair programming? Not only do I find it socially awkward, it completely kills my productivity. Software development is often about building a very complex model in your head and then figuring out the changes that need to be made. Having to dedicate half of my mental bandwidth to handling socia…
If you have two people working with each other, then you have to worry if each person is a fit for the problem ... and if they're a fit for each other. Or you have to worry if they are each partially a fit for that problem such that the two of them count as being fit for the problem (and they still have to be a fit for each other). And you also have to keep an eye on overall productivity. You're billing at 2x the rate, so you had better be seeing some noticeable benefit to justify it.
I've had good experiences and bad experiences pairing. I suspect that people who like it a lot already have a bunch of experience solo developing and are generally able to get along with a large number of people. Also, they're probably solving easy problems with an overabundance of budget.
Re: Uncomfortable Truths in Software Engineering
#300Earlier quoted context omitted.
I don't understand this weird fetishism with getting X demographic into software/tech. Naturally I don't think that any demographic should be restricted from entering the field, and everyone should be equally encouraged and provided the same opportunities, but more and more I see these pushes for trying to pump the numbers of specific demographics. If someone wants to join the industry, great. If not, also great. I t…
I think it's based on the assumption that if all cultural factors were removed, an equal number of men and women would be in software engineering. And so, by modus tollens, the current gender ratio of the industry is a damning indicator of how much cultural bias still needs to be fought against. Personally I think that's a flawed assumption. While there are certainly cultural biases at play still, there are also aggr…
Part of the reason that I don’t think your paragraph 1 assumption is flawed is that there is evidence that men and women were equally interested in programming before the 80’s, but that a combination of cultural and societal factors came into play in that decade that branded computers as a “boy thing” and resulted in women being pressured out of the pipeline from a young age.
But even if you can find some sort of counterargument for that, my overriding reason why I stick with this assumption is as follows: decade after decade, people insisted that women weren’t into $career. And one by one, women have found their way into those careers (factory work in WWII, the executive suite more recently, plenty of other examples in between). In each case, the people saying women weren’t into $career had an argument that seemed to make sense, often relying on some combination of status quo statistics and hand-wavy conclusions drawn from psychology. And they were wrong. So when I see those same arguments brought out again for this career (often with some exhortation that “this time is different”) I generally dismiss them, as the epistemology they’re based on has a bad track record.
With all that being said, when it comes to actions, I’ll be more likely to encourage women to get into programming if I get a sense they might be interested in it. However, when it comes to interviewing candidates, I will not grade people on a curve based on their identity, as it is my belief that men and women can in fact be equally good at programming and should be held to the same standard.