|
Bruegels Fuckbooks posted:One thing that can really gently caress up a project is having too many people on it when it starts. It sounds like you have too many people on the project. What's funny is that there's only about 4 of us in the immediate vicinity, but there's still like 12+ stakeholders Elsewhere and that one UI/UX team that I have never seen before. It's hard to get a handle on who is involved in this project, due to the sheer size of the company. I'm probably overthinking this. I'm just gonna watch how this goes for the first bit, and work on learning about agile and all that over time. Sarcasmatron posted:There seems to be some conflation of Agile and Scrum. This is good poo poo. There's a lot I don't know about the entire process, and I'm still not sure if the Agile I experienced at my last company was quite the kind of methodology I want to be a part of. Right now, I'm just reading The Agile Samurai, and so far it makes a lot of sense - but I don't think it's the be-all-end-all of it. I'm not sure what else I should be reading and learning to help figure out the team's methodology/improvement. I just want to be able to share real insights and get things on track when we spend 45 minutes arguing about fields on a data model 
Pollyanna fucked around with this message at 11:27 on Jan 27, 2016 |
#
?
Jan 27, 2016 11:24
|
|
|
|
| # ? Apr 23, 2024 22:57 |
|
|
Sarcasmatron posted:There seems to be some conflation of Agile and Scrum. The way I see it: Agile is not a methodology. Any software development process can be called agile (lower case) if it adheres to the values and principles of the manifesto for agile software development. Scrum is a methodology as it prescribes a specific software development process that is (pretty) agile. I agree with the 'training wheels' description in the sense that it's a "learn the rules before your break them"-thing. It's very useful for that. Kanban does not really prescribe a process but is more of a way to continuously improve your existing process. Other practices and techniques such as continuous delivery, DDD and (A)TDD combine well with agile processes. For me the most important part of it all is being able to deliver working (and valuable) software early and often, getting customer feedback, and incorporating that feedback.
|
|
#
?
Jan 27, 2016 14:00
|
|
|
I'm about to  out of here, holy balls.Working on 1 of several "disciplined agile delivery" teams. The Business, i.e. product managers and project managers are still 100% waterfall. They still want us to do time estimates for every task and story, track time spent, etc. Since Product is waterfall, there is no backlog, there is a project backlog where all the waterfall'd specs were entered into TFS as work items. Then, each team commits someone to the maintenance hunger games as tribute to be the "maintenance person" for that sprint. That means, they are expected to spend 80% of their time pull poo poo from the "maintenance backlog". There is no Product Owner (in the agile sense) or Scrum master and any team could have 3-4 sources that drive prioritization. So, of course there's lots of omgfire emails asking devs to drop everything and fix this thing that everyone ignored for a year and oh no here comes the waterfall deadline and/or Federal auditors. I've been telling these people since I started "this is going to break unless you get some product owners and/or scrum masters". Welp, can't do that because there's too many products with too many product managers and there aren't enough dev teams to dedicate one team to a product. My response has been "Then organize into business units. half these products are basically the same thing, anyway." Meanwhile, I'm staring at a help desk ticket I submitted 6 loving months ago to get IS Security approval for installing Atom on my desktop. Don't get me started on that mess. What they don't know is that I have 2nd interview at a place next week that follows every item on the Joel Test and gives devs Aeron chairs, free lunch every day, and free sodas. (I asked management to consider free drinks for devs and got told "nope, too expensive for a company our size".) But Google/Miscrosoft do it... "we're not doing it, kthx". Not saying that free drinks is the most important thing, but the culture here is pretty toxic. I could see this place being the best place to work in this market in like 5 years, but they've about beaten all the fight out of me, at this point.
|
|
#
?
Jan 27, 2016 20:51
|
|
|
Has anybody ever actually had the luxury of a product owner who: - knows what she's talking about - has mandate to make decisions - is available day to day? In my experience two out of three has been the maximum.
|
|
#
?
Jan 28, 2016 08:46
|
|
|
Crossposted from the front-end thread as I didn't realize nobody's posted there in a week, sorry! -- I hope this is the right place, looking for some insight. I just graduated with a BSc in compsci and I've been offered a frontend position at a startup, which is owned by a huge company in my country, for pretty decent pay considering I have no real-world programming experience. I'll be using JavaScript, React, Async, and Redux, and will apparently be given some exposure to backend (my preference) and mobile development. Now the hosed up part, I never used any of those technologies throughout my degree. The last three I'd never even heard of until I started researching after the interview. I was very up-front about my experience and was assured it wasn't an issue, though I was made aware that I "will be learning a gently caress load". The whole thing seems bewildering to me but I'm committed now, or at least intend to be after I receive the contract and it checks out - provided I'm not about to make a stupid mistake. That said, one of my circle of friends is made up of mostly mid-senior developers and a couple architects who've all seen my work, and assured me that I'll be fine. So far, I've picked up the javascript fundamentals from Codecademy and I'm in the process of trying to wrap my head around React from the obvious resources I could find, and I'll be spending the weekend doing the same for Async and Redux. I'm also in the process of building every basic javascript app I can find tutorials for. For reference, all my spare time is spent with coding, at the gym, gaming, or with the missus so I'm not worried about being able to fit in a lot of research and practice in my own time, after work, as it'll probably be necessary. My question - am I hosed, or is it likely that since I have no experience outside of uni I'm overthinking the difficulty of being thrown into several technologies I've never heard of? Finally, could anyone recommend some learning resources for the four things I've listed? Thanks.
|
|
#
?
Jan 28, 2016 09:10
|
|
|
Click Beelay posted:Crossposted from the front-end thread as I didn't realize nobody's posted there in a week, sorry! This sounds completely normal to me. I am currently still in my second year for my BSc, but I've also been working as a developer for about a year now. I don't remember a single junior who started during this year who knew anything about any kind of framework - even in Java or Python, which are the main languages taught in the big universities here. They just knew how to do school assignment type things. Honestly frameworks aren't that hard to pick up. My advice to you: think of some specific web project, something simple. A blog, a forum, something like that. Then just try to build it using the software and tools you'll be using at work. Use documentation, stackoverflow, if you can find some tutorials then that can be a good starting point. Just keep it simple so you can finish it in a few days, maybe a week. In my opinion, that's the best way to learn a new technology.
|
|
#
?
Jan 28, 2016 09:21
|
|
|
Illegal Move posted:This sounds completely normal to me. I am currently still in my second year for my BSc, but I've also been working as a developer for about a year now. I don't remember a single junior who started during this year who knew anything about any kind of framework - even in Java or Python, which are the main languages taught in the big universities here. They just knew how to do school assignment type things. Probably the most reassuring thing I've heard yet, I've likely been focusing a little too much on the fundamentals, gonna dive into a project. Thanks.
|
|
#
?
Jan 28, 2016 09:36
|
|
|
Click Beelay posted:Crossposted from the front-end thread as I didn't realize nobody's posted there in a week, sorry! Hello, fellow "new to the real world of programming" buddy!  You're basically in the same position I was ~8 months ago. It's not so hard, trust me. You'll almost certainly be working with an established codebase and experienced colleauges. These both give you a foundation to work on, and nobody is going to expect you to start cranking out full systems from the day you land. Just ask a ton of questions and abuse the hell out of your VCS, and you'll be up and running pretty drat quick.
|
|
#
?
Jan 28, 2016 14:53
|
|
|
Messyass posted:Has anybody ever actually had the luxury of a product owner who: Two out of three's about as good as I've had it too. I'm lucky in that my product owners have mostly been of the first two, but that ends up being mutually exclusive with the third because if they know what they're talking about and can make impactful decisions then they're in very high demand.
|
|
#
?
Jan 28, 2016 15:27
|
|
|
Yeah, my PO was all three until they went, "You're good at this!" and gave her a second team.
|
|
#
?
Jan 28, 2016 16:09
|
|
|
Messyass posted:Has anybody ever actually had the luxury of a product owner who: Yeah, I've had a PO that did all those, although it was a small team where the PO was also the senior architect and worked closely with the Director (basically the Business) to manage his expectations and do the whole "Okay, we can certainly work on this, but which of these other priorities should get bumped to make room in the next iteration, etc." But really, as a dev, I don't need a PO that does #2 and #3. Dev should have the mandate to make decisions (about implementation, anyway). I don't need daily checkins from the PO, really. My understanding of Agile is that the PO translates requests from the Business into user stories and working with the Scrum Master (if there is one) to groom and prioritize the backlog.
|
|
#
?
Jan 28, 2016 21:21
|
|
|
Click Beelay posted:Crossposted from the front-end thread as I didn't realize nobody's posted there in a week, sorry! Doesn't sound hosed to me. Sounds like typical programming job. As a backend guy, I would definitely manage expectations about doing frontend work, but with these modern js frameworks, it ends up being a lot like backend code anyway; you'll end up with models, controllers, etc. that follow some very similar paradigms, but instead of making calls against a database, you're making calls against an AJAX service.
|
|
#
?
Jan 28, 2016 21:25
|
|
|
Click Beelay posted:Now the hosed up part, I never used any of those technologies throughout my degree.
|
|
#
?
Jan 28, 2016 21:35
|
|
|
Finster Dexter posted:But really, as a dev, I don't need a PO that does #2 and #3. Dev should have the mandate to make decisions (about implementation, anyway) Decision making by the PO is not supposed to be about implementation. POs need to have the ability to make decisions about prioritization and requirements, and unfortunately I've had far too many experiences where the PO's prioritization is overridden by executives or other jokers who just want to satisfy the latest biggest deal. As a dev you absolutely want to have a PO who has the mandate to set and maintain prioritization so that you don't end up with unnecessary whiplash.
|
|
#
?
Jan 28, 2016 21:40
|
|
|
csammis posted:Decision making by the PO is not supposed to be about implementation. POs need to have the ability to make decisions about prioritization and requirements, and unfortunately I've had far too many experiences where the PO's prioritization is overridden by executives or other jokers who just want to satisfy the latest biggest deal. But that sounds correct. Business sets the priorities. Product Owner is there to make sure the new priorities are reflected in the backlog, not to decide whether or not Priority A is more important than Priority B.
|
|
#
?
Jan 28, 2016 22:43
|
|
|
Finster Dexter posted:But that sounds correct. Business sets the priorities. Product Owner is there to make sure the new priorities are reflected in the backlog, not to decide whether or not Priority A is more important than Priority B. That's actually kind of exactly what PO does. The team does what the PO says needs doing, period (as opposed to CFO or whoever barging in). If a stakeholder absolutely requires the team to work on something, then she talks to the PO and the PO rearranges the product backlog. How the stakeholder manages to compel the PO arrange the backlog to reflect her priorities may vary. The business guy may feel it's very important for the team to drop everything and make a feature, but the lawyers may feel it's even more important to comply with some regulations by some deadline, the security officer may feel it's most important to fix a glaring vulnerability, etc. It's the PO's job to ultimately make these decisions for the team. pigdog fucked around with this message at 23:01 on Jan 28, 2016 |
|
#
?
Jan 28, 2016 22:56
|
|
|
ChickenWing posted:Hello, fellow "new to the real world of programming" buddy! Hah, thanks! I naively expected to be thrown in the deep end on a project of my own but now that I think about it that's retarded. Can't wait to start. Finster Dexter posted:Doesn't sound hosed to me. Sounds like typical programming job. As a backend guy, I would definitely manage expectations about doing frontend work, but with these modern js frameworks, it ends up being a lot like backend code anyway; you'll end up with models, controllers, etc. that follow some very similar paradigms, but instead of making calls against a database, you're making calls against an AJAX service. The guy interviewing me mentioned a lot of the same things when talking about how, initially, he wants me exposed to all aspects of development so this is reassuring as hell, thanks. NoDamage posted:This is completely normal. The degree teaches you theory/fundamentals, not any specific technologies (which generally change too quickly to be taught in school). Would be nice if they taught some basic software engineering skills though (like version control), considering most CS graduates will end up in the industry afterwards. Awesome, thanks. Everyone seems to mirror the feelings of the people I've talked to IRL, apparently I was severely overthinking everything. I mirror your feelings about a compsci degree though, Git and more web development practise than "Assignment X: build thing in HTML/CSS/PHP" would have been great; it makes sense that they don't bother with frameworks though, never thought of it that way.
|
|
#
?
Jan 29, 2016 02:49
|
|
|
pigdog posted:That's actually kind of exactly what PO does. The team does what the PO says needs doing, period (as opposed to CFO or whoever barging in). If a stakeholder absolutely requires the team to work on something, then she talks to the PO and the PO rearranges the product backlog. How the stakeholder manages to compel the PO arrange the backlog to reflect her priorities may vary. The business guy may feel it's very important for the team to drop everything and make a feature, but the lawyers may feel it's even more important to comply with some regulations by some deadline, the security officer may feel it's most important to fix a glaring vulnerability, etc. It's the PO's job to ultimately make these decisions for the team. I see what you are saying, I think, and yeah, you're right. So, in setting up a PO, Dev needs to establish that they're the department that decides when and how things are worked on, then. Which I also believe.
|
|
#
?
Jan 29, 2016 06:04
|
|
|
Finster Dexter posted:I see what you are saying, I think, and yeah, you're right. So, in setting up a PO, Dev needs to establish that they're the department that decides when and how things are worked on, then. Which I also believe. I would argue that the developers and the PO are somewhat separate (in particular, the developers decide how they're going to get something done), but in general, yeah. The PO, or more to the point, a single person, needs to have the authority to be the final say on priorities, and management has to agree that once the team chooses what it's going to work on, that it's not going to change until the end of the sprint (barring extreme emergency). Otherwise the devs are going to just get jerked around by various interested parties and will never get to concentrate on anything. That doesn't mean the PO can't get it wrong or get called to the woodshed by executives if he prioritizes poorly. But if he's doing that he's not doing his real job, which is communicating with stakeholders and with his own company's management and developers and figuring out what the product should BE in the first place.
|
|
#
?
Jan 29, 2016 22:17
|
|
|
Click Beelay posted:Now the hosed up part, I never used any of those technologies throughout my degree. The last three I'd never even heard of until I started researching after the interview. I was very up-front about my experience and was assured it wasn't an issue, though I was made aware that I "will be learning a gently caress load". When I graduated college, Ruby on Rails was still in version 1, and among my fellow students, I'd only heard it once or twice, as a "hey, I heard about this thing, and it's interesting, but not worth using yet" sort of thing. Also, the iPhone wasn't out yet, and mobile was definitely not a thing. Hadoop was not a thing, and I don't remember ever hearing about "big data" in school. We did all of our AJAX calls by hand in my Internet Programming course; at that time, jQuery didn't even exist yet. Neither did node.js. Or Angular. Or whatever the new hotness is. Stack Overflow did not exist. There was no Github (git wasn't even particularly well-known; we used SVN in my one class that mentioned version control). My Software Engineering class focused primarily on waterfall, because agile was "just a fad". We never talked about writing unit tests or anything like that. Some of that might have been the failure of my professors, but some of it was simply that some things were just not as widely known about in the software engineering world. That's just the nature of the industry: things change quickly, and new technologies arrive on the scene. It's much less (in my opinion) about whether or not you've used each technology; it's much more about being able to pick up new stuff and keep building. Learn how to keep getting better.
|
|
#
?
Jan 31, 2016 05:58
|
|
|
Axiem posted:When I graduated college, Ruby on Rails was still in version 1, and among my fellow students, I'd only heard it once or twice, as a "hey, I heard about this thing, and it's interesting, but not worth using yet" sort of thing. Also, the iPhone wasn't out yet, and mobile was definitely not a thing. Hadoop was not a thing, and I don't remember ever hearing about "big data" in school. We did all of our AJAX calls by hand in my Internet Programming course; at that time, jQuery didn't even exist yet. Neither did node.js. Or Angular. Or whatever the new hotness is. Stack Overflow did not exist. There was no Github (git wasn't even particularly well-known; we used SVN in my one class that mentioned version control). My Software Engineering class focused primarily on waterfall, because agile was "just a fad". We never talked about writing unit tests or anything like that. It's rad to know that other people had a similar experience at uni, I'm fuckin stoked if all I have to do is be willing to continuously learn and improve; poo poo's half the fun of coding for me.
|
|
#
?
Feb 1, 2016 03:15
|
|
|
If you're stoked to do that and genuinely believe that it's important, then you'll be fine.
|
|
#
?
Feb 1, 2016 06:13
|
|
|
Axiem posted:When I graduated college, Ruby on Rails was still in version 1, and among my fellow students, I'd only heard it once or twice, as a "hey, I heard about this thing, and it's interesting, but not worth using yet" sort of thing. Also, the iPhone wasn't out yet, and mobile was definitely not a thing. Hadoop was not a thing, and I don't remember ever hearing about "big data" in school. We did all of our AJAX calls by hand in my Internet Programming course; at that time, jQuery didn't even exist yet. Neither did node.js. Or Angular. Or whatever the new hotness is. Stack Overflow did not exist. There was no Github (git wasn't even particularly well-known; we used SVN in my one class that mentioned version control). My Software Engineering class focused primarily on waterfall, because agile was "just a fad". We never talked about writing unit tests or anything like that. While true, there are things now that are Known that should be taught, but aren't. Rutgers CS STILL does not teach students about version control! Versioning has been a thing for decades, it'd be great if they accepted that it wasn't a fad.
|
|
#
?
Feb 1, 2016 16:51
|
|
|
Without digressing into specific ways that CS departments may or may not meet the needs of their students, most CS departments are an absolute shitshow. As a project my final year of college, I did an assessment of the college's curriculum, working with the department secretary. We found that the department didn't even have quantitative data on the students in order to make reasonable decisions about what they should be teaching. They had no idea of who came in to gain a theoretical grounding in computation versus people who wanted to learn skills for a development job, they had no idea what outcomes were for people graduating from the program. They didn't know the math SAT scores of incoming students and they didn't even have the retention rate for how many students who declared computer science as a major were still in the program a year later. We asked to present our findings at their annual curriculum design meeting and discovered they didn't have one (they do now). You could maybe understand this somewhere in the humanities, but this is a department whose job is literally to teach students how to use data to solve problems and they just. don't. give a poo poo.
|
|
#
?
Feb 1, 2016 17:14
|
|
|
I hope you found the same in the Statistics department 
|
|
#
?
Feb 1, 2016 19:13
|
|
|
Far as I can tell the only number colleges look at is how much money they're making.
|
|
#
?
Feb 1, 2016 19:24
|
|
|
Vulture Culture posted:Without digressing into specific ways that CS departments may or may not meet the needs of their students, most CS departments are an absolute shitshow. As a project my final year of college, I did an assessment of the college's curriculum, working with the department secretary. We found that the department didn't even have quantitative data on the students in order to make reasonable decisions about what they should be teaching. They had no idea of who came in to gain a theoretical grounding in computation versus people who wanted to learn skills for a development job, they had no idea what outcomes were for people graduating from the program. They didn't know the math SAT scores of incoming students and they didn't even have the retention rate for how many students who declared computer science as a major were still in the program a year later. We asked to present our findings at their annual curriculum design meeting and discovered they didn't have one (they do now). My previous job was running an on campus team of developers, and we had about 6 full-timers, and about 12-18 students. The best student developers were always the Info Systems majors from the business school, because their curriculum spent significant chunks of time creating software solutions for real-world companies in the local area. The IT major guys were usually pretty good, too. CS majors were good kids, but they could always be counted on to submit pull requests that contained some kind of overengineered, impossible to maintain solution that would be guaranteed to break when faced with edge cases and be super-hard to refactor. Most of my time was spent training them in basic design patterns and un-teaching them some of the horrible habits the CS dept seems to love like monolithic methods and classes, inherit all the things, etc. Like all a modern CS department would need to do is teach C#/java, basic design patterns, SOLID, algorithm analysis (Big O), RDBMS, and stuff like that. Leave the compiler writing and other stuff to graduate courses, IMO.
|
|
#
?
Feb 1, 2016 19:30
|
|
|
Finster Dexter posted:My previous job was running an on campus team of developers, and we had about 6 full-timers, and about 12-18 students. The best student developers were always the Info Systems majors from the business school, because their curriculum spent significant chunks of time creating software solutions for real-world companies in the local area. The IT major guys were usually pretty good, too. Speaking as a self-taught developer who never got a proper education, I'd totally be down for turning DEVELOPMENT into a trade school skill, whereas Computer Science prances back to the land of algorithm theory, etc, in academia. I've met way too many people with Masters of Comp Sci. on their resume who will shout all day about 'Separation of Concerns!', 'Dependency Injection!', and the like, but then ask them to *implement* anything and it turns into a muddled mess because they spent more time memorizing abstract flowcharts describing good patterns, rather than learning the HOW to implement them and WHY to use them in practical terms. "You must unit test!" they cry - then write a unit test where they mock the method-under-test to return string.Empty, then assert that it returns string.Empty - at which point they pat themselves on the back about 'Good code coverage.'
|
|
#
?
Feb 1, 2016 19:44
|
|
|
Where I went we actually had to take a Software Engineering course that covered things like overall architecture, readability, and maintenance. Our OOP class also covered some pretty useful organization concepts but in retrospect we just didn't cover enough organizational stuff. I ended up learning it on my own through reading about software engineering further but I cringe at some of the things I saw other students writing. We covered Waterfall but not version control. There were also practical classes like web dev and whatnot but the core was theoretical.
|
|
#
?
Feb 1, 2016 19:54
|
|
|
Cuntpunch posted:I've met way too many people with Masters of Comp Sci. on their resume who will shout all day about 'Separation of Concerns!', 'Dependency Injection!', and the like, but then ask them to *implement* anything and it turns into a muddled mess because they spent more time memorizing abstract flowcharts describing good patterns, rather than learning the HOW to implement them and WHY to use them in practical terms. "You must unit test!" they cry - then write a unit test where they mock the method-under-test to return string.Empty, then assert that it returns string.Empty - at which point they pat themselves on the back about 'Good code coverage.' None of those things are part of academia. Sometimes bad developers get masters degrees to try to mask that they're bad.
|
|
#
?
Feb 1, 2016 20:01
|
|
|
I think this belongs in this thread: I got a bug to translate some month names on a simple table where they're the column headers, so I just iterated over the names the (.Net) framework already has in a convenient global culture settings object. Easy-peasy. Submit that for review only to get told to write a test to make sure the array is populated  Maybe we need a :tdd99: but I'm not sure how to communicate "masturbating to useless tests" in a smiley.
|
|
#
?
Feb 1, 2016 22:13
|
|
|
Ithaqua posted:None of those things are part of academia. Sometimes bad developers get masters degrees to try to mask that they're bad. What I'm saying is that people go so goddamn hung up on these *ideas* without *practical application* that means a drat, that they end up figuring if they can quote SOLID or draw a Factory Pattern, that's all that matters. Want to develop software? Great! It's a cool job! But learn it by *DOING IT* not by *reading about it*. The constant fallback of the bad developer to tropes and terminology just points to me as a failing of spending too much time *reading* about how nails work, rather than hammering wood together.
|
|
#
?
Feb 1, 2016 22:25
|
|
|
Cuntpunch posted:What I'm saying is that people go so goddamn hung up on these *ideas* without *practical application* that means a drat, that they end up figuring if they can quote SOLID or draw a Factory Pattern, that's all that matters. Want to develop software? Great! It's a cool job! But learn it by *DOING IT* not by *reading about it*. The constant fallback of the bad developer to tropes and terminology just points to me as a failing of spending too much time *reading* about how nails work, rather than hammering wood together. I can't refute what you are saying because, to be fair, I've encountered very few "bad" developers. I've met a lot of inexperienced developers that just needed the right training and experience.
|
|
#
?
Feb 1, 2016 22:33
|
|
|
Man, I always thought my school had a poo poo CompSci program. It gets a bad rap from a lot of other schools in Canada. It's good to know that apparently US schools are much worse  Seriously how do you get out of university without knowing big-O.
|
|
#
?
Feb 2, 2016 15:30
|
|
|
In my school, most people don't learn a whole lot about actual software development. I feel like the reason for this is that we're expected to do a lot of math. There's one course during the second year where you work on a pre-existing software project, and one course during the third where you build a complete software project. I heard a lot of people talk during these courses about how they constantly had problems with their "annoying version control", setting up databases and other very basic things. On the other hand, everybody learns a LOT of math. And not just practical math, but (in my opinon) relatively worthless things. We're expected to learn something like 100 math proofs every year (depending on what math courses we have that year). We're not really taught software development basics, and I think a big reason why a lot of people don't learn about the basics during their free time is that most of their free time is taken up by doing math homework. We recently had a survey where the students were asked what they wanted to do with their education. The vast majority answered that they wanted to be software developers. A handful of people answered something like "analyst" or "sysadmin". Only a couple said they wanted to do actual science. Also, in my country, school is payed for by taxpayers. The government decides how many people get to study each field based on industry demand. Computer Science always has a lot of open spots (in my university it's around 150 new students each year, and it's increasing). So obviously, the government wants the university to produce a lot of software developers as well. So based on that, the current math to software development ratio in my school doesn't make any sense, it should really be the opposite of what it is now.
|
|
#
?
Feb 2, 2016 15:49
|
|
|
ChickenWing posted:Man, I always thought my school had a poo poo CompSci program. It gets a bad rap from a lot of other schools in Canada. tbh, yesterday was the first time I've ever needed to know Big O, professionally. And that was because it was a job interview. They asked me what the Big O was of the LINQ OrderBy method. I guessed polynomial time. I was wrong. It was logarithmic. But they didn't seem to care and I don't care either.
|
|
#
?
Feb 2, 2016 16:20
|
|
|
Finster Dexter posted:tbh, yesterday was the first time I've ever needed to know Big O, professionally. And that was because it was a job interview. You really should, it is rather important.
|
|
#
?
Feb 2, 2016 16:27
|
|
|
Finster Dexter posted:They asked me what the Big O was of the LINQ OrderBy method. I guessed polynomial time. I was wrong. It was logarithmic. But they didn't seem to care and I don't care either. That's a stupid question. "Take a wild guess at what sorting algorithm is used by a framework method that you're unlikely to have ever looked at the source to". If they told you what sorting algorithm it used, that's a different story, although it's still a stupid question that comes down to memorization.
|
|
#
?
Feb 2, 2016 16:30
|
|
|
Yeah, like just at a fundamental level you should know algorithms if you're doing any sort of programming, and big-O is a fundamental part of algorithms.
|
|
#
?
Feb 2, 2016 16:30
|
|
|
|
| # ? Apr 23, 2024 22:57 |
|
|
Ithaqua posted:That's a stupid question. "Take a wild guess at what sorting algorithm is used by a framework method that you're unlikely to have ever looked at the source to". "Polynomial" is a silly answer though, unless they use bubble sort or something. "Logarithmic" sounds wrong too, though, maybe they mean n*log(n)?
|
|
#
?
Feb 2, 2016 17:03
|
|
