there were less than 5 girls on my computer science class, so unless woman are claim that they should have the job without education. I can totally see the reason why there is a gender diversity in IT?
This data point isn't super useful without telling us the total size of your class. 5 out of 5–10 is great, 5 out of 25–50 might be realistic, 5 out of 100+, not great.
same here (tough we were 32 guys and 3 women). - germany, still have relationship with teachers, they barly see more than 3 girls/30 in 5 classes per year.
"IT Professionals" is a broad label. Maybe we can think of getting a 'degree in a field' as a proxy-variable for 'interest in the field'. What's astonishing to me is through the 60s, 70's and into the mid-80s, computer-tech interest in female cohorts tracked with science, law and medical fields. Then it flattened and fell, while female participation in those other three fields continued to expand at the rates they had before. (So, what happened in 1985?)
Thanks for that link. My original sighting of the phenomena used the exact same graph, but made no attempt at being explanatory. I have since then, been searching, but failed to re-find a copy of that graph to stick into my files. Now, thanks you you, I have! Thanks!
Firstly, that isn't true. Huge numbers of people learn to write code as part of a degree that isn't CS - for example, if you want someone to develop a GIS startup you'd be better off with a geography graduate who can write decent code than a CS graduate who probably doesn't have experience of GIS.
Secondly, if you hear "startup" and think "developers" then you're ignoring at least 50% of the work necessary to make the business a success, all of which can (and often should) be done by someone without a CS degree. There's a lot more to tech than writing code.
as DevOps Borat says - "agile waterfall". Agile causes deadlines to be tighter because agile causes huge inefficencies, especially when it comes to inter-team/project/module interactions and dependencies, and pile of additional unnecessary stuff to be done that takes additional energy/resources/time to burn to deal with and which gets in the way of the stuff what is really need to be done.
A snake oil - be it agile or communism - is easy to identify by the fervency with which its peddlers preach no true Scotsman.
Agile doesn't cause more inter-team interactions and dependencies; that's an orthogonal issue. In general dependencies can be minimized by organizing around feature teams instead of component teams. But you can do the same thing with a waterfall process.
>Agile doesn't cause more inter-team interactions and dependencies;
It doesn't cause more of them, it makes them fail.
> In general dependencies can be minimized by organizing around feature teams instead of component teams.
You can't include common core upstream components into downstream branching features. Basic topology of a tree. Until of course you just have only one team doing the whole project.
Even when components with a dependency between them are in the same team the dependency still exists and agile makes it much more harder to handle. Until i guess it is one person doing both components - that by transitive closure would mean one person doing all the project himself (until the project component graph contains disconnected islands)
You're missing the point. The agile manifesto — and the various agile methodologies in common use today — don't mandate any particular practices around reuse of common core upstream components.
If you want to divide the teams up by component rather than by feature you can do that, but it's usually a bad idea. Most projects can achieve higher velocity and quality by having teams take on vertical slices of functionality through the full software stack; this minimizes misunderstandings and delays when handing off work between teams. But either way it's essential to have stable APIs and clear design contracts before building any dependencies on top of common core upstream components. Again this is all orthogonal to agile versus waterfall.
Also, a real agile development cycle started from OO design, you need to design the code well enough that each object is relatively isolate from each other before we can talk about Agile.
nowadays, every organization talk about agile development cycle, but few business ppl really spend time to understand what it is, and how much it is involved.
like one of the poster here said, "Agile waterfall"
Well that is one approach and it sometimes works. But usually it fails or least forces excessive rework because much of what you thought you knew at the beginning of the project later turns out to be incorrect. Another more agile approach is to avoid big up front design. Treat design as an emergent property and keep the internal OO design clean through constant refactoring.
>But either way it's essential to have stable APIs and clear design contracts before building any dependencies on top of common core upstream components. Again this is all orthogonal to agile versus waterfall.
in the ideal world you'd have that stable API, contracts, and delivered components satisfying them from day 0. In the real world you have back and forth iterations which are just fine under waterfall and which are heavily impeded to the point of impossibility by the sprint cycling in agile. On practice in waterfall the upstream and downstream components are developed almost in parallel, and they have active feedback cycle between them. On practice in agile you can't really start consuming a component until it reaches the stage of deep maturity (and reaching such stage under waterfall is significantly faster due to almost immediate feedback cycle from downstream components as mentioned above) and that makes agile process into super-slow component dependency serialized process, a "component-wise waterfall".
There is nothing in agile which prevents upstream / downstream teams from working in parallel and iterating on components. Nor does agile require that components reach the stage of deep maturity before they are consumed; in reality it's completely the opposite. I can't fathom where these misunderstandings are coming from.
Again, if your project is organized in component teams then you're likely to have those problems regardless of methodology. The optimal solution in most cases is to reorganize around feature teams, plus have a small cross-team group of technical experts for each major component who can provide stewardship and review major changes.
>There is nothing in agile which prevents upstream / downstream teams from working in parallel and iterating on components.
a task (for example acting on a feedback, fixing a bug, etc.) can't be taken in mid-sprint because it would affect the sprint's deliveries and thus a replanning mid-sprint would be needed which thus makes all this ritualistic sprint belly-dancing pointless. So, the downstream has to wait until next sprint for any actions by the upstream wrt. the feedback while that downstream is still responsible for meeting its current sprint deliveries which it has hard time to satisfy given the unsatisfactory delivery state from the upstream. After being burnt this way several times the downstream team finally learns from experience and refuses (or fights pretty heavy against management pressure) to take on in a given sprint any tasks which depend on components which haven't reached deep maturity by the sprint's start or any maturity at all and hell no to any promises that that upstream is coming down mid that sprint (any deliveries from upstream, even if scheduled for mid-sprint actually almost always come at the end of the sprint). And if it is the first version or a major change you can't even seriously plan on working with it next sprint - see feedback sprint cycle above - the best you can hope is the end of the sprint next after the next... That makes even idea of iterative parallel process pretty much impossible, a bad joke slow as toothache.
>Again, if your project is organized in component teams then you're likely to have those problems regardless of methodology.
Agile worsens these issues couple orders of magnitude compare to traditional relaxed [i.e. we aren't coding F-35] waterfall.
No that's not the correct way to do agile project management. As I have repeatedly pointed out, you can prevent most upstream / downstream iteration delays by organizing the project around feature teams, not component teams. But if you persist in using component teams for some reason then obviously both the producer and consumer teams must build in sufficient time into their story point estimates for iterating on the interface. As for defects that come up mid-sprint, either every team should keep a percentage of their capacity in reserve, or on larger projects you should dedicate a full Kanban team to maintenance.
Sure there are some managers out there who implement agile incorrectly by failing to follow best practices. But all of the problems you described are self-inflicted and easily avoided on agile projects with competent leadership.
technically speaking, no I m not paid to write code, if ask that question during an interview, company would tell you that they dont pay you to write code as well.
However, when most of the companies's idea of "agile" development cycle is to have smaller goals and very short deadlines, you end up being a code monkey. A project may run better if you have time to design a better object structure, instead because of a tight deadline, we have to slap on 10 if and else if statements then call it a day.
when making an enhancement? add 2 more if statements, fix a bug? put some if statements under the previous if statements.
bottom line, because of the tight deadline, better code and better design means nothing. we become if statements code writing monkeys.
It can come back.... by having a trade war with China, by raising the tax on Chinese Imports. I lived in China, a pair of Levis made by factory down a block is 100 bucks(and chinese make way less monthly), but when it export to USA, its 60 a pair.
What happens when tariff is raised and a pair of Levis from China now have to sell 120 bucks a pair? and if you produce that in US, since you dont have tariff, its 60 bucks a pair? what you think factory is going to do?
Trade wars are a horrible idea, won't work and will just harm the overall economy. Nearly every economist agrees that free trade is a net gain for everyone involved. Moving to something like a trade war which defies all rational economic sense is a terrible idea and I hope Trump is not dumb enough to do something that drastic.
every economist also said market was going to crash yesterday. Free trade is a horrible idea, specially when your trade partner dont play on the same rule you play on.
One of the reasons those jeans are $60 is because the labor is cheap. Import tariffs might bring back jobs, but no way you'll be able to pay the workers the wage they're looking for and keep the cost of goods the same.
My question is if the cost of goods will rise enough to make wage gains irrelevant, or if the effect won't be strong enough and we'll see real wage gains.
you didnt see my point, Chinese put heavy tariff on the import to protect their local economy. therefore a pair of jeans thats created locally going to sell more expensive then it is oversea.
when you have a 100 bucks a pair Levis vs 5 bucks a pair of local made jean (which came out of same factory), Chinese are most likely to buy the 5 bucks one, and therefore Chinese govt effectively protect their local business, took job from USA and helped every local economy with American investing dollars.
you dont take the CS class to learn a language... you do it to learn the concept of programming and how computer "ticks". CS education is not suppose to train a coder, but a capable person who can adapt the new language, concept or technology and run with it.
I m not sure why you bring Trump into this, he has nothing to do with Terrorist organization, unless you are trying to say that American Govt is a form of terrorist groups, but in that case, Bush and Obama has been the head of that group for the past 16 years.
I'm not sure I explained my comment right in that case. I bring Trump into this because he represents an anti-Muslim voice in the global media and this i significant for the point I'm trying to me. He simply a nice and current example of my little theory here.
Notably I do not mean to get involved in the American election debate.
The more power and attention Trump gets, the more Muslim youths in the West feel repressed and despised. This helps ISIS and similar organizations. It's not a stretch to imagine that more radical Muslim terrorism in the West, should it occur soon, will benefit Trump, and thus the cycle is complete. This is the kind of dynamic that moves people to the fringes, away from tolerance and moderate political opinions.
The awful acts that you mention that Obama and Bush were responsible for were not accompanied with a similar anti-Muslim rhetoric and that breaks this cycle, somewhat at least. This is why I did not bring them up. Note that strictly seen, only one side needs to actually do violence for a cycle like this to spin out of control. It's most important both sides need to commit to a powerful anti-the-other-people rhetoric.
So if you run an extremist organization looking for more power, all you have to do is pick and then provoke an enemy whose leadership you know will make your target audience / electorate feel very uneasy. This is what ISIS is doing and Trump, more than other American politicians, is helping them do it. It's been done many times before, think Rwanda or how Hamas got into power in Gaza.
I don't completely care about the exact definition of terrorism in this case - it's more the observation that acts of indiscriminate violence against people from a certain group puts people from that group up against the group the violence doers are from. Terrorism is one such kind of indiscriminate violence and usually the easiest to apply unless you're a nation state.
no this wasnt a election debate, thats why i failed to see why brought Trump into the conversation. the Hatred between Christian and Muslims can go back all the way to Crusaders. Regardless of how much Anti-Muslims comment Trump made, Radicals wont hate him more. The more neutral and logical comment Obama made, wont make Radicals like him better.
911 happened during Bush administration, but i m sure Bin Laden spent years during Clinton administration to plan. Point here being, who leads the supposed free world doesnt matter, Radicals will hate you. Its in their blood, flow though their veins though generations of unfair treatments from western world.
Look back how western world treated them, ever wonder why there are so many countries in mid east, and wonder why there are so many conflicts happens there every year?
I guess my points are that at this point, your simple existence is enough to provoke the radicals, regardless who is head of govt. Bangazhi didnt happen cause whole world like Obama better and Bush less. Hands of Jesus Christ are just as bloody, he sent just as much people to meet their maker.
To me, its different philosophy, I never consider Apple very innovative technically. they have always been (even with jobs) more innovative on product strategy and marketing. Iphone wasnt the first of its kind, nor its Ipod. However, They have always choose the correct package for a stable technology that fits the mass.
Buying Iphone, Ipod, IMac, or air its more of a fashion statement than a Technical one, and coding does look cool on Mac, and time may be changing, but most people that i know who code on Apple product arent your typical computer science, nerds with no art back ground kind of coders.
> Apple product arent your typical computer science, nerds with no art back ground kind of coder
The art background comment is funny. I don't really know what all my colleagues studied in school, half of them probably don't remember. But I work with a lot of backend distributed systems people, very little visual UI type work. Most of us use macs because of unix. And that's important because we deploy to Linux. While not the same exactly, it's close enough to build comparable tools between both.
Apple has hands down, the best portable Unix on the market. They should play to that audience more, rather than just a side note.
I would also like to add, Microsoft are and had been innovative, they may not making some digital woman who you could talk to on the phone, but how to make OS more efficient and take the advantage on all the new hardware, how to fit windows this giant monsters on all the new hardware, in itself is pretty amazing.
Yeah. Honestly, I don't want Windows. What I want is a really solid durable hardware platform for running Unix. One day maybe I will try a surface with Linux, I wonder if MS has crippled that or not. Anyone know?
yeah, I know about the Linux compatibility in Windows. But I don't want Windows ;)
So Linux is good enough for me, but on the Laptop there are still many issues, like waking from sleep. Apple has an excellent product, but on the day that I decide that I need to switch, then I'll probably also try to contribute to help fix the Linux issues.
American dont stink at Math, American stinks at training kids in general, you cant give too much home work, kids need time to play, and the Chinese kid in China is at school till 9 pm constantly doing and practice math. yeah, an avg American kid is not going to be as good as avg Chinese kid.
However, the top 3-5% of the American kid is going to be just as good if not equal to their Chinese counter parts.
In China, education made all kids above avg regardless if you are below or above intellectually. In America, an idiot is going to be an idiot, and a genius will take that step to be a genius.
The most beautiful and elegant part of coding is the logic, Not how to use a for loop. Anything question that can be answered with google should be forbid from a interview test. show him a method, ask him how he can improve the performance. ask him a opinion based question on OO design.
if you hiring a house builder u would not ask him what a brick looks like right?
if you hiring a house builder u would not ask him what a brick looks like right?
The problem with this is that a home builder/contractor will have a long list of references, and possibly examples of her work available for examination. Many engineers search for jobs while still employed, so they generally don't include as references co-workers and current managers. Further, if your employer doesn't allow you to open source your work, then you need to do open side projects to have any sort of real resume prospective employers can examine (and this is problematic since your day job may already take more than 40 hours of your time).
So, no, I don't need to ask a contractor if he knows what a brick looks like, but I do need to look at his references, look him on Angie's List, post to local message boards about his work. And, of course, I'm not an expert on home building, so it would be unreasonable to ask him questions about carpentry or framing.
I see where you're going, and I generally agree with you, but I think that every programmer should at least be able to FizzBuzz, just as every architect or master home builder should be able to answer the question "which one of these is a brick?"
I think there is no point in assessing anything that doesn't take years to learn. And it's fairly easy for any team to come up with some fundamentals, that a candidate should know. There are more important qualities, than knowledge, though, as google-funded research suggests, like empathy.
