|
ChickenWing posted: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. Big-O is pretty theoretical in its way but where I went there's an entire class on it that only CS majors are expected to know. However, in the second programming class overall there are projects that point out the difference between inefficient, brute force algorithms and more elegant ones. The big one that we went through when I took it was calculating prime numbers. I think that's probably the only thing a programmers needs to know; there are algorithms that work but are impractical but other algorithms that might not be obvious but are way more elegant. The actual analysis class spent like a month on sorting algorithms and their differences alone. We started with bubble sort and then the professor said "never use bubble sort ever." That led into a really in depth, theoretical analysis of how time complexity works and why it's important. Granted he'd also say things like "in the real world you'll rarely need to talk about this stuff but understanding it will make you better at programming."
|
#
?
Feb 2, 2016 18:25
|
|
|
|
| # ? Apr 27, 2024 02:43 |
|
|
I once had a standup meeting that lasted over an hour. At 60 minutes on the button I sat down in protest. Nobody said anything. It was rare for things to run over 20 minutes with that group though.
|
|
#
?
Feb 3, 2016 02:23
|
|
|
Bongo Bill posted:I once had a standup meeting that lasted over an hour. At 60 minutes on the button I sat down in protest. Nobody said anything. Why the hell didn't you leave? I leave / disconnect when the 15 minute meeting time expires.
|
|
#
?
Feb 3, 2016 02:34
|
|
|
Virigoth posted:Why the hell didn't you leave? I leave / disconnect when the 15 minute meeting time expires. If a manager is running a 60 minute "standup," they do not understand Agile. Therefore, they will not understand an employee walking out of one of their meetings after 15 minutes, and will likely reprimand the employee. gently caress, if a manager is running a standup at all. My boss likes to come in to ours uninvited, but at least he's learned to mostly keep his mouth shut during the thing and ask questions of specific individuals afterwards. Che Delilas fucked around with this message at 03:11 on Feb 3, 2016 |
|
#
?
Feb 3, 2016 03:06
|
|
|
Virigoth posted:Why the hell didn't you leave? I leave / disconnect when the 15 minute meeting time expires. It would have been topographically awkward, as the meeting was taking place directly outside my non-soundproof door.
|
|
#
?
Feb 3, 2016 03:10
|
|
|
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. Very fundamental aspects of software design like pervasive mutability vs pervasive immutability, use OOP implementation inheritance vs not, or static typing vs dynamic typing cannot be agreed upon.
|
|
#
?
Feb 3, 2016 04:03
|
|
|
comedyblissoption posted:Working professionals in the industry in general cannot agree on what good software design looks like. "Good" software design is extremely controversial! One thing every good developer can agree on is that they're incompetent and how have they gone this long without anyone figuring this out, I mean did you SEE that module I just wrote? Jesus.
|
|
#
?
Feb 3, 2016 04:25
|
|
|
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". You don't need to guess the specific algorithm at all. You should also be able to answer questions like, "what is the big O of this ORDER BY query (given certain indexes)" without knowing the precise internal machinations of a database engine. And then give an estimate of the round-trip latency depending on how big the dataset is / how big rows are. And the way you'd come up with the answer is, "it's using a {b-tree|hash table|none of the above}, so obviously blah blah blah." The operative word there being "obvious." sarehu fucked around with this message at 08:52 on Feb 3, 2016 |
|
#
?
Feb 3, 2016 08:50
|
|
|
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. If I remember correctly, technically you were correct, since big o defines an upper bound of the algorithmic complexity.
|
|
#
?
Feb 3, 2016 09:30
|
|
only
|
sarehu posted:And then give an estimate of the round-trip latency depending on how big the dataset is / how big rows are. Would anyone actually ask this? Real-world read speed and query-to-result is going to be dictated by pressures on the database engine by other queries and memory / tempdb caching, not just table size. ...or did I just give the best answer? 
|
|
#
?
Feb 3, 2016 14:44
|
|
|
I was recently hired as a Requirements Engineer at the frontend branch of a software development company. I have about as much IT-knowledge and experience as your average goon and a humanities degree with a professional background in media and journalism. I cannot write a line of code to save my life. My main task will be to work with the PO and produce good user stories. My team more or less uses Scrum and they aim to follow it more closely. I`m in for one hell of a ride. What I'm asking is, I guess, do you guys have any thoughts regarding requirements engineering? Do you have tips on what to read up on regarding the position in general and the writing of user stories in particular?
|
|
#
?
Feb 3, 2016 15:06
|
|
|
csammis posted:Would anyone actually ask this? Real-world read speed and query-to-result is going to be dictated by pressures on the database engine by other queries and memory / tempdb caching, not just table size. TDWTF is littered with examples of terrible developers looking for a row in a table by doing SELECT * and then iterating over the results. Even if the database responded instantaneously, it's still an O(n) vs O(1) operation. As your data sizes get larger and larger, having a grasp on the complexity of your queries and your critical sections can have outsized results.
|
|
#
?
Feb 3, 2016 15:59
|
|
|
Volmarias posted:TDWTF is littered with examples of terrible developers looking for a row in a table by doing SELECT * and then iterating over the results. Even if the database responded instantaneously, it's still an O(n) vs O(1) operation. As your data sizes get larger and larger, having a grasp on the complexity of your queries and your critical sections can have outsized results. I think he was just referring to the part about being asked to estimate the approximate latency, not the time complexity. But yes, you've highlighted quite nicely why I cringe every time someone claims that "big O" is something they'll likely never need to know or think about in the work place.
|
|
#
?
Feb 3, 2016 16:05
|
|
|
Yeah I agree that understanding the complexity of a database operation is important. It was sarehu's comment about latency which confused me into wondering why anyone would ask about that specifically.
|
|
#
?
Feb 3, 2016 16:06
|
|
|
sarehu posted:You don't need to guess the specific algorithm at all. The original question wasn't about a database query at all
|
|
#
?
Feb 3, 2016 16:07
|
|
|
Steve French posted:You really should, it is rather important. You're right, at least theoretically. Practically speaking, knowing BigO keeps me from doing stupid things like dumping everything out of a database table unnecessarily or being flippant with nested for loops. But honestly, those were things I instinctively knew to watch out for before I'd ever heard of O(), anyway. Outside of basic uses like that, I've never needed to re-implement a sorting algorithm or anything like that. If I did, I would spend 5 minutes googling and have the most efficient sorting algorithm right at my fingertips.
|
|
#
?
Feb 3, 2016 16:35
|
|
|
Fluegel posted:I was recently hired as a Requirements Engineer at the frontend branch of a software development company. I have about as much IT-knowledge and experience as your average goon and a humanities degree with a professional background in media and journalism. I cannot write a line of code to save my life. My main task will be to work with the PO and produce good user stories. My team more or less uses Scrum and they aim to follow it more closely. I`m in for one hell of a ride. http://www.amazon.com/User-Stories-Applied-Software-Development/dp/0321205685
|
|
#
?
Feb 3, 2016 16:44
|
|
|
This one also http://www.amazon.com/User-Story-Ma...+mapping+patton
|
|
#
?
Feb 3, 2016 19:27
|
|
|
csammis posted:Would anyone actually ask this? Real-world read speed and query-to-result is going to be dictated by pressures on the database engine by other queries and memory / tempdb caching, not just table size. I wasn't recommending that as an interview question, my point is that it's the sort of back-of-the-envelope awareness that is useful in real life at real jobs. Big O is the first step, more specifics are the second. Like this one coworker I had once whose answer to problems that could easily be solved by batching SQL queries was to bring in some blades he happened to have lying around at home, because he just didn't get it. Being able to say "this'll bring a ~33x speedup" and have it turn out to be 30x is quite useful when you're deciding what to do. It's like avoiding homeless people in San Francisco: you're better off with a hill-climbing algorithm than blind search.
|
|
#
?
Feb 3, 2016 22:17
|
|
|
Fluegel posted:I was recently hired as a Requirements Engineer at the frontend branch of a software development company. I have about as much IT-knowledge and experience as your average goon and a humanities degree with a professional background in media and journalism. I cannot write a line of code to save my life. My main task will be to work with the PO and produce good user stories. My team more or less uses Scrum and they aim to follow it more closely. I`m in for one hell of a ride. I'm officially a Requirements Engineer as well. The position is in a bit of weird place nowadays because it's not like the role exists in Scrum or anything. Ideally you'd have the developers talking to the PO and other domain experts directly anyway. On the other hand, writing good user stories is still a skill. And i'm not talking about the 'as a ... i want ... so that ...' part, but about the acceptance criteria / tests. Since we're recommending books: http://www.amazon.com/Specification-Example-Successful-Deliver-Software/dp/1617290084 Basically, don't be this guy: https://www.youtube.com/watch?v=n3Sle_o1bcs
|
|
#
?
Feb 4, 2016 12:02
|
|
|
Things pissing me off: holy fuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuck why did we take half an hour out of our 1.5 hour meeting to talk about which parts of a single 30 word blurb of text are dynamic  I really hate people who make it their meeting-mission in life to have a very long and protracted opinion on every single point
|
|
#
?
Feb 5, 2016 19:20
|
|
|
I'm totally stoked because I finally solved an issue that had been plaguing me for probably two weeks. I had made some changes to a job that ran regularly. Due to a bad merge (or a good merge, but with unexpected integration side-effects), one of the tasks was failing at startup. I dug around for a while, found the issue, and fixed it. Shortly thereafter, a subtask was raised saying the task was running three times. I, having just hosed with the code, figured I'd hosed up. I tried digging around, thinking maybe there was an old copy of the application scheduler sitting around on the machine, but nope. Okay, said I, I'll just roll back my change. Still seeing it. Maybe the integration/import screwed up things? Ugh. The job was scheduled to run every five minutes, so it was a matter of "make change, recompile, deploy quickly, wait," while juggling other tickets and keeping the higher-ups happy with sprint velocity. "Maybe the task is failing and rescheduling itself? Maybe it's a race condition with two workers grabbing the same task? Maybe it's maybeline." After getting nowhere for a week, putting a breakpoint, marching up and down the function, I had to consult the stupidly obvious solution that I should have considered from the get-go. Maybe the task and code are fine, but there are multiple copies of the scheduler running. I shut down the scheduler on the machine and wait, letting tail -f dump the log to console. Two copies scheduled. Progress! Now I know there are two machine on the network that are running the scheduler. How? We've only got maybe three machines under our supervision. The QA environment is fine. Staging is fine. Staging scheduler is fine. I've killed the scheduler on all those boxes, but still two tasks are made every five minutes. I sit, listening with netstat for connections. Unfortunately, the connection seems to be negotiated and closed faster than netstat can pick it up. I finally dump connections that are made to the database and see two machines that I didn't know about. One of them is a sparkly new development machine that was just given to us. The other is unknown. I ask around the office. Turns out that someone on another team asked for an instance of our application so he could play with our not-yet-released software. DevOps made a clone of our staging environment and didn't change any of the environment variables, so we had two schedulers pointed to the same workers. In hindsight, it's a stupidly simple problem I should have solved quickly, had I not been confused by a coincidence in timing.  ? Yes, but I'm so glad it's solved.
|
|
#
?
Feb 5, 2016 19:33
|
|
|
ChickenWing posted:Things pissing me off: e: and I just stumbled across this: http://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction Vulture Culture fucked around with this message at 19:42 on Feb 5, 2016 |
|
#
?
Feb 5, 2016 19:35
|
|
|
Vulture Culture posted:To avoid bikeshedding, we moved towards just asking developers to implement requirements however they think is appropriate. We spend less time reimplementing things that people don't like than we did talking about them before I tried proposing this approach in my team and the lead developer balked at the idea that anyone might do anything even remotely differently from someone else on the team. I wasn't surprised. I knew there would be trouble the first time we had a team-wide meeting about how to capitalize object names in our code.
|
|
#
?
Feb 5, 2016 19:57
|
|
|
GlitchThief posted:I tried proposing this approach in my team and the lead developer balked at the idea that anyone might do anything even remotely differently from someone else on the team. I wasn't surprised. I knew there would be trouble the first time we had a team-wide meeting about how to capitalize object names in our code. That sounds like an argument in favor then. "Since we will all do the same thing anyway let's just do it."
|
|
#
?
Feb 5, 2016 21:04
|
|
|
Hughlander posted:That sounds like an argument in favor then. "Since we will all do the same thing anyway let's just do it." The issue is we won't all do everything the same way (i.e. the way the senior developer prefers) until we discuss it at length.
|
|
#
?
Feb 5, 2016 21:18
|
|
|
I can't convince my team to loosen the PMD rules that enforce Javadoc. So 95% of our public methods look like:code:
|
|
#
?
Feb 6, 2016 19:41
|
|
|
And do the remaining 5% have the inline documention out of sync with the code?
|
|
#
?
Feb 7, 2016 16:51
|
|
|
dividertabs posted:I can't convince my team to loosen the PMD rules that enforce Javadoc. So 95% of our public methods look like: Yeah I loving hate that poo poo. The only thing that might be useful in the comment (the description of what the method is intended to do and why) is optional, everything else is mandatory.
|
|
#
?
Feb 7, 2016 17:09
|
|
|
The inverse is just as bad. There was a group of leads/architects who insisted that all code should be self-documenting and therefore there isn't a need to comment the code base. One of them for some reason didn't see the irony of saying that at the same time that he's scratching his head over what two functions do and why they're invoked in the order they are. During the code review of said functions that he himself wrote the week before. Dogmatism of any sort is just bad.
|
|
#
?
Feb 7, 2016 18:30
|
|
|
Hughlander posted:The inverse is just as bad. There was a group of leads/architects who insisted that all code should be self-documenting and therefore there isn't a need to comment the code base. One of them for some reason didn't see the irony of saying that at the same time that he's scratching his head over what two functions do and why they're invoked in the order they are. During the code review of said functions that he himself wrote the week before. Sometimes people make it to lead/architect without learning this 
|
|
#
?
Feb 7, 2016 19:43
|
|
|
This is a good thing to watch (ignoring the "catchy" title); https://www.youtube.com/watch?v=a-BOSpxYJ9M TL;DR - agile as a noun ruined everything, and: quote:Find out where you are I'm getting tired of "2 week waterfall" 
|
|
#
?
Feb 8, 2016 00:41
|
|
|
Hughlander posted:The inverse is just as bad. There was a group of leads/architects who insisted that all code should be self-documenting and therefore there isn't a need to comment the code base. One of them for some reason didn't see the irony of saying that at the same time that he's scratching his head over what two functions do and why they're invoked in the order they are. During the code review of said functions that he himself wrote the week before. I guarantee the comment would have ended up like this: code:
|
|
#
?
Feb 8, 2016 01:14
|
|
|
evensevenone posted:I guarantee the comment would have ended up like this: He spent twenty minutes trying to rename the methods into what would make sense.
|
|
#
?
Feb 8, 2016 01:18
|
|
|
Hughlander posted:The inverse is just as bad. There was a group of leads/architects who insisted that all code should be self-documenting and therefore there isn't a need to comment the code base. One of them for some reason didn't see the irony of saying that at the same time that he's scratching his head over what two functions do and why they're invoked in the order they are. During the code review of said functions that he himself wrote the week before.
|
|
#
?
Feb 8, 2016 04:13
|
|
|
Fluegel posted:I was recently hired as a Requirements Engineer at the frontend branch of a software development company. I have about as much IT-knowledge and experience as your average goon and a humanities degree with a professional background in media and journalism. I cannot write a line of code to save my life. My main task will be to work with the PO and produce good user stories. My team more or less uses Scrum and they aim to follow it more closely. I`m in for one hell of a ride. Take this with a big grain of salt, as I've never been fortunate enough to work in a place where there was someone dedicated just to writing decent specifications (which are ... wonderful when you have them, speaking as an engineer).  1) In addition to user stories, since you mention being in a frontend group, consider reading up on UI / UX in general (if nothing else, you'll be a good sounding board for the PO that way). I'm a backend engineer and sometimes ops person so sadly I have no specific references to books or whatever to give here. 2) As part of UX, on top of textual user stories, consider whiteboarding / wireframing tools to give visual guidance as well. Sometimes a picture's worth a thousand words. What does the user see when they do something? Literal pencil-on-paper-scanned-in can work here. I've also heard good things about Balsamiq, fwiw, but have not used it (see above re: being a backend nerd). 3) It wouldn't hurt to dabble a bit in how this stuff is done; you don't have to be a developer, but it helps to have some fluency so you know better what is in (and out) of the realm of technical feasibility. Nobody was born knowing any of this, we all learned somehow. 4) Don't panic! Your background has already prepared you for the crucial bit of translating/recording things in one domain for an audience in a different domain. You'll definitely have a learning curve but ... as mentioned, everyone has to start somewhere.
|
|
#
?
Feb 12, 2016 20:41
|
|
|
The Book Apart series is written for web development, but there's a ton of excellent UI/UX and general design goodness contained within. https://abookapart.com/
|
|
#
?
Feb 13, 2016 16:53
|
|
|
Thanks for these, managed to get the first one ordered through the company and bought the other one for myself. Tremendous help in getting a grip on the theory. Messyass posted:I'm officially a Requirements Engineer as well. The position is in a bit of weird place nowadays because it's not like the role exists in Scrum or anything. Ideally you'd have the developers talking to the PO and other domain experts directly anyway. It's weird since I'm not really part of the whole Scrum-Framework and basically get to do a little bit of everything wherever it helps. What I am trying to do is correlate information, get the right people talking to each other and deliver whatever information the developers need post-haste. At the moment I'm struggling with getting the right information out of huge technical spec documents and translating it into bite-sized pieces the developers will understand. This will take time I reckon. volkadav posted:Take this with a big grain of salt, as I've never been fortunate enough to work in a place where there was someone dedicated just to writing decent specifications (which are ... wonderful when you have them, speaking as an engineer). Thanks for the feedback! 1) I made a push to tidy up the language used in our user stories and actually creating something akin to understandable acceptance criteria. I got a general sense for UI and UX when I was dabbling in Game Studies academically but I could definitely use more knowledge on that front. 2) I've been playing around with Balsamiq and did some test wireframe concepts, I really like to program. A little Mockup really goes a long way in making a concept understandable. 3) I've been trying to wrap my head around how our stuff works as quickly as possible. It's hard to really get into the code and deeply technical stuff but yes, it helps tremendously to be at least competent at the most important user interfaces and whatnot. It'll be a long while until I can make sense of any code. 4) I'm trying not to get in over my head and just improve step by step. It's a steep learning curve but yeah, I feel up for it. At least for the moment. Famous Last words right here.
|
|
#
?
Feb 16, 2016 19:51
|
|
|
I am in charge of a new project that is upgrading our old product + RTOS into a new board + Linux. The first question I had was "Where are the cad schematics." The first answer I got was "We don't have those and the people we contracted out to never made them/don't have them." 
|
|
#
?
Feb 17, 2016 03:58
|
|
|
|
| # ? Apr 27, 2024 02:43 |
|
|
Java devs: how do you feel about intellij idea? I'm working with Spring Tool Suite at work (Spring-focused eclipse distro) and I'm interested in seeing what idea has to offer, but I'm having issues finding out how to do all the stuff I'm used to doing in eclipse and I want to know if it's worth it or not.
|
|
#
?
Feb 23, 2016 15:20
|
|