|
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
|
|
|
|
| # ¿ May 2, 2024 08:50 |
|
|
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: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. I used to think that programming in Java was a chore, but after switching to intellij, I actually like Java.
|
|
#
¿
Feb 23, 2016 19:37
|
|
|
How many of you have to log your time on JIRA or something similar? Where I work, everybody is expected to log all working hours on the tasks they work on, and I'm wondering how common it is. I feel like nobody at my office actually honestly works for 8 hours every day, but if you don't log all the hours, you get angry e-mails from management. I definitely have some days that are less productive than others, so sometimes I end up logging 2 hours on a task that really probably only should have taken 30 minutes. I'm starting to feel really guilty about this, and I keep thinking that somebody will question me about it and I'll get fired, but in reality, my team seems to be really happy with my work. Am I an rear end in a top hat for sometimes stretching the time I log?
|
|
#
¿
Mar 6, 2016 22:11
|
|
|
In case anybody is interested, this is the e-mail we get at my office when we haven't logged 8 hours every day: (this is then followed by a list of the people who didn't log all their hours)
|
|
#
¿
Mar 8, 2016 14:50
|
|
|
Jo posted:I pushed a change to our QA branch and the database access count went through the roof after a deploy. I said, "Hey X, I think the problem is related to this operation. Could you take a look?" to give him an out in the hopes that he'd recognize his mistake (a missing prefetch) and fix the problem. Instead, he replies all, "Hey, Jo, your code broke this and caused the storm. I fixed it." He removed a non-functional line that I had added and, in his commit, also subtly included a fix for his fuckup. Wow, sounds like X is a dipshit.
|
|
#
¿
Mar 11, 2016 08:57
|
|
|
Everybody at my company in every team had Lync set up on their computer. I've yet to encounter a single team that actually uses Lync - most teams just use Skype.
|
|
#
¿
May 13, 2016 22:04
|
|
|
How exactly does paid time off work in US based software companies? I mean, I have a general understanding that US labor laws don't really aim to protect/help average citizens, but surely software companies need to step up and offer good conditions in order to keep their devs happy? Seeing how there's always a shortage of developers. Just as a point of reference, I just finished planning my vacation schedule for this year. I get 55 days of paid vacation, because: 1) Everybody in my country gets 28 days by default 2) I work for the government, all government employees (including teachers, police, etc) get an extra week 3) I'm in my last year of uni, and all university students get 20 extra days of paid vacation every year (basically it's meant as time for focusing on school). In addition to all that, I can get unlimited paid time off for medical reasons every year. My expectation has always been that if I some day decided to work for a US based company, I could still get similar conditions, but based on the previous posts here, I'm starting to doubt this. Can anyone clear it up for me?
|
|
#
¿
Jan 27, 2017 12:20
|
|
|
Polio Vax Scene posted:Not gonna lie I made some data display by drawing in a Canvas once because I didn't want to deal with arranging some divs properly. Wow, we really need display: grid; to be widely supported already.
|
|
#
¿
Feb 11, 2017 01:19
|
|
|
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
|
|
|
Messyass posted:REST basically just means "JSON over HTTP" now and we'll have to accept that. I'll keep stubbornly complaining about people using "REST" when they really mean "HTTP" until I die thank you very much
|
|
#
¿
Apr 3, 2019 09:09
|
|
|
"Relaying a question from our developers: do you intend to complete this integration using traditional SOAP requests or will we be using the newer REST requests?" Translated to English from an actual e-mail in my inbox. A few e-mails later it turned out that the reason he was asking was that whatever framework his developers were using was apparently much faster at handling json than xml so clearly "REST requests" were the better design choice
|
|
#
¿
Apr 3, 2019 09:22
|
|
|
I've seen a few attempts at structuring HTTP APIs to look like REST so that each endpoint represents a resource or a collection of resources. Eventually it always just becomes this weird masturbation over translating actions/procedures into resources (because endpoints can only refer to resources or collections). I've seen people argue for replacing `POST /login` with `POST /login-attempts` because the first is an action not a resource therefore it's not ~~REST~~ therefore it's ugly and can't be used (meanwhile the API isn't REST anyway as REST is basically useless without an AI client but hey whatever)
|
|
#
¿
Apr 3, 2019 16:05
|
|
|
Hollow Talk posted:An API I had the immense pleasure of pulling data from a while ago didn't really understand any of this, or that there are HTTP Requests Methods other than GET. Need to delete something? GET. Need to upload something? GET. Need to retrieve something? GET. I always think of this anecdote when people mention side-effects on GET requests
|
|
#
¿
Apr 3, 2019 20:42
|
|
|
Ither posted:AI client? Don't get me wrong, REST is great and dumb REST clients are used every day (browsers for example), but they need an actual human to click on links and stuff to actually get anywhere. Without a human, REST APIs don't make any sense. When people say "we have a REST API", they generally mean "we have an HTTP API that may or may not look similar to REST in some ways, but probably isn't really REST". Imagine a world where people actually use REST APIs for machine clients: You need to create an app for letting your users manage ads on a sweet social network. They have a REST API, so all you get is the root endpoint - https://socialnetworkapi.com. You ask for more documentation, but they tell you that it's a proper REST API, just follow the trail of crumbs from the root URL. You start making requests to figure out what the resource tree looks like and what operations you can do on each resource. You write down all the requests you'll need for creating ads and adding pictures to them and getting stats and so on. As you submit your first pull request, the senior developer reviewing your code asks you if you're mad. "Why did you hardcode all these endpoints? It's a REST API! The endpoints can change at any time!". You go back to the drawing board and start thinking of ways to automatically navigate the API using just the root URL and HATEOAS. 50 years of hard coding go by and you finally manage to create a client that can successfully create ads on social network using a REST API. Sadly, it turns out the client is self-aware and it murders all humans. The End. sunaurus fucked around with this message at 13:04 on Apr 4, 2019 |
|
#
¿
Apr 4, 2019 12:34
|
|
|
Wow looks like there's a bunch of cool opinions on these last few pages, here are some actual facts though: 1) There is nothing wrong with RPC-style URLs (POST /do-complex-operation), anybody who tells you otherwise is dumb (and so is trying to turn complex procedures into resource-based urls for no loving reason other than deluding yourself into thinking you're doing REST) 2) REST is much more than just having resource-based URLs. REST-style collection-resource URLs are totally OK for simple apps, especially if you can put a lot of your business logic in whatever client will be using your API, but just because you have URLs like /things/1 does not mean you have a REST API. 3) Actual REST is not something that you need to be doing for an API that is consumed by a machine. HATEOAS is a stupid waste of time. 4) Using HTTP response codes as application error codes can be very bad. You get 404 from an API, what just happened? Did someone break their nginx configuration? Maybe there's a bug in their application url routing logic? Maybe they just changed their endpoint without telling anybody? Or is a resource actually missing from their database? There's no way to know! Sending a proper error code and (and possibly an error message) in the response body can give API users a lot more confidence in their assessment of what the gently caress is wrong. Kevin Mitnick P.E. posted:Things that matter, in order: This guy seems like a cool and pragmatic developer, everybody should try to be more like this guy.
|
|
#
¿
Apr 5, 2019 23:07
|
|
|
Volguus posted:Let me give you a hint: nobody ever reads the drat docs unless is the last resort (that is, nothing they've tried so far works). You can force internal developers to read your docs for your API, sure, an external developer would just laugh in your face. Well this is definitely one the strangest opinions I've encountered so far this year
|
|
#
¿
Apr 5, 2019 23:14
|
|
|
Volguus posted:However, doing a "POST GetShit" is fundamentally wrong. Philosophically, realistically, experimentally, wrong. Don't do that. You're absolutely wrong here. I think you're under the assumption that POST means "create", but it certainly doesn't. If you were to say "PUT GetShit" is fundamentally wrong, you would be right - PUT has a very strict semantic meaning in HTTP, it either replaces or creates something. It's different with POST - all POST means is that the server must process the request according to the specific rules of that endpoint. Nothing needs to be created on the server as a result. If you define an endpoint like /get-something, then it's perfectly valid to have that endpoint process a request like {id: 1} by returning an existing something with the id 1.
|
|
#
¿
Apr 6, 2019 08:26
|
|
|
I'm actually extremely surprised at the amount of posters here thinking that half-assed REST is a good way of designing HTTP APIs. I feel like this discussion is starting to go in a circle, so let me just summarize what my point has been all along: REST does not equal HTTP. Claiming that all HTTP APIs must be built using REST semantics (not HTTP semantics) is just odd. REST does not equal CRUD. HTTP verbs do not equal CRUD. Also, most real-world HTTP APIs are not just CRUD. As someone who has had the pleasure of consuming a wide variety of HTTP APIs, I definitely agree with the posters saying that any type of API with consistent design and good documentation is awesome to use. I've also run into tons of half-assed REST APIs created by developers who have an incomplete understanding of REST (which I'm guessing they got from some blog or stack overflow or something), these have not been so fun to use. From some of the posts I've seen here, I assume a bunch of you will remain unconvinced and keep thinking that HTTP verbs for CRUD + resource-based URLS (which is NOT enough to be REST anyway) is some sort of holy grail of API design. I guess that opinion will change at some point when people start blogging less about REST and more about whatever the next API fad will be, so I'm just going to stop posting about HTTP and REST. sunaurus fucked around with this message at 17:34 on Apr 6, 2019 |
|
#
¿
Apr 6, 2019 17:22
|
|
|
Metaphors are awesome. Even incomplete metaphors can be great for explaining some specific thing at some specific level. Of course some metaphors are much better than others, but even if a metaphor can only be applied to software development partially, it can still be used to understand those specific aspects it applies to.
|
|
#
¿
Apr 15, 2019 13:17
|
|
|
shrike82 posted:A very broad question to the developers/engineers out there - how would you characterize the good (technical) managers you've worked with? And in contrast, the poor ones? In my experience, "leading by example" is usually not a good thing. It can create this weird situation where the technical manager overworks himself in order to try and motivate others, and others start relying on the manager too much for everything. Also, it has the potential to really frustrate the manager, because he'll be thinking "I'm working so hard to motivate everyone else, why aren't they getting it?". What I always ask from my managers is to very clearly set expectations and be brutally honest in feedback. If you're not happy with what I'm doing, don't try to motivate me by "leading by example", just be direct and tell me what you want from me. Work just seems to flow much better when the whole team knows what's expected of them and if they're meeting those expectations. With that in mind, here's what I think a good manager is like: 1) Their main focus should always be to build a great team. This means that when the team needs a new member, the manager needs to make sure that the right person gets recruited. Also, people who don't fit in the team get removed. And of course, the manager must ensure that all team members have the resources for constant self-improvement. 2) They need to stay out of the day-to-day work of engineers. A manager doesn't need to "OK" everything or always know what every single team member is working on every hour of the day - this is just stupid overhead. 3) Like I said before, they need to be clear about what is expected from the team. 4) They need to be constantly removing any obstacles from the team's way. Ideally, they'll be dealing with problems before the team even knows about them. From what I've seen, very few managers are actually like this, but the ones that are have definitely been amazing to work with. sunaurus fucked around with this message at 11:42 on Apr 17, 2019 |
|
#
¿
Apr 17, 2019 08:32
|
|
|
Boiled Water posted:What do you do when you want to remove people but don't have anything to replace them with? I've gone through this once, it took ~6 months, and it went roughly like this: For the first few months, we did our best to onboard a new dev (who was actually an old dev in the company but new to our team), but we kept gradually running into weirder and weirder problems with him: 1) He insisted on using a different IDE than the rest of the team (not a big deal in isolation but it kept causing weird problems for him) 2) He used a local mercurial repo which he synced to our remote git repo (again, caused some weird problems) 3) He kept insisting on keeping all communication to phone calls instead of using async communication methods 4) In the same vein, he basically had his own version for every single tool or process that our team used and he always got visibly upset when something he wanted to use was incompatible with what the rest of the team was using 5) He lied a lot about his progress with different tasks and even what he was actually working on (this was the major problem with him really, but we didn't figure it out until a few months in) - he would say on a Monday that he would work on some feature which was blocking someone else, and then later that week we would ask him how it's going and he would shock everybody by saying something like "yeah it's pretty good I can start working on it probably tomorrow" We tried a few different things, early on we were all pretty optimistic that we could accommodate him and that he would come around to our way of doing stuff if he ever felt his way was causing too much friction. In reality, his productivity never went up, he kept stubbornly using his own tools for everything and having problems with them, and we even noticed that the rest of the team was also losing a lot of productivity because we were spending time dealing with him in different ways. I think he had been in our team for around 4 months when we decided that we didn't want to work with him anymore. We had plenty of data about how he was bringing down the productivity of the team (we were doing scrum at the time, so we could show a lower velocity, but also we had documented just a bunch of different ways that he had been causing problems for the team). It took another few months of management and HR talking to people in our team and the dev in question, trying to find solutions other than getting rid of him, but eventually management agreed with the team and we got rid of him. On the one hand, I'm quite proud of that team for fixing its problems even if it means firing someone, but on the other hand, 6 months is probably way too long to handle someone who is bringing down a whole team.
|
|
#
¿
Apr 17, 2019 12:48
|
|
|
Volmarias posted:HR wanted to be sure they were safe against an age discrimination suit? lifg posted:How did it go down? Was he put on a PIP? I don't know the details of what went on between him and HR sadly. He found out he was leaving before the rest of the team did, I think most of the team awkwardly heard it directly from him and he didn't really share much details.
|
|
#
¿
Apr 17, 2019 17:22
|
|
|
vonnegutt posted:If I know what IDE my coworkers are using, it's a problem. I don't agree - if multiple people in the team (the majority?) want to use a jetbrains IDE, then it makes perfect sense to check in the .idea folder. How would this even cause merge conflicts if you don't have a different local copy of the files? That would be a conflict-free merge. In the specific team I wrote about, we had for example shared stuff like our code autoformat settings and a bunch of database connection settings. We never forced anyone to use intellij, but since everyone preferred jetbrains IDEs, it made sense to share the settings. The new guy wanted to use eclipse instead, and we definitely didn't tell him that he couldn't, but he ran into a bunch of problems with getting his editor to not reformat all of our code on all his commits and he also had some problems with getting live reload to work (everybody other than him used the jrebel plugin for intellij and nobody knew how to help him troubleshoot it on eclipse). Keep in mind, I only brought the IDE thing up to paint a better picture of how he wanted to do everything his way. I'm definitely not saying that people using different IDEs in one team is somehow inherently bad for team productivity.
|
|
#
¿
Apr 17, 2019 18:43
|
|
|
Keetron posted:The .idea folder contains more than a few settings and I have some specifics with how I set up my IDE and do not want anybody's grubby settings near mine. The personal stuff (workspace.xml, user dictionaries, some other things) are always .gitignored anyway. https://intellij-support.jetbrains.com/hc/en-us/articles/206544839-How-to-manage-projects-under-Version-Control-Systems
|
|
#
¿
Apr 17, 2019 19:01
|
|
|
It's not that you can't work on Java without an IDE, it's just that IDEs work so well, it's stupid not to leverage them. For the past half a year, I've been working on a project without any Java, and I'm constantly being surprised at how bad IDE support can be in other languages. Just a few days ago, with Python, I was trying to refactor (rename) a method on a class named `get` (a completely brainless and foolproof operation with java code), and my editor found something like 2000 false positives for usages of this method. It was showing me all usages of any method named `get` on any class, not just the class I was refactoring. At that point, the 'rename' refactor is about as useful as a 'find and replace' (which of course is not very useful on a large codebase). I'm also constantly running into similar issues with Javascript, and even with Typescript! You would think that refactoring would be easier with static types, but somehow, Typescript refactorings are not there yet. But I can totally see why Python or JS devs for example don't get IDEs - the IDEs just aren't as good with those languages as they are with Java-based languages.
|
|
#
¿
Apr 17, 2019 21:04
|
|
|
lifg posted:It's more then that. Java code slowly becomes optimized for the features of a good IDEs. It's funny you say that, because I've also heard the exact opposite argument: "IDEs cause developers to create a bunch of small classes that are impossible to navigate without an IDE" People who like huge classes will create huge classes, people who like small classes will write small classes. I have not noticed any correlation between IDE usage and class size preference.
|
|
#
¿
Apr 17, 2019 22:10
|
|
|
My issue with setting up vim with enough plugins to turn it into an IDE is pretty much the same as my issue with most "Need an important feature? Just use a plugin!" type software: 1) Plugins end up conflicting with each other 2) It can become really hard to keep track of all the configuration for all your plugins 3) There is no central documentation for how stuff works 4) Overall UX ends up being bad I often see these same problems with stuff like Jenkins and even VS code. I don't think plugins are bad, but something that's designed from the ground up to be an IDE (like intellij for example) will probably be much easier to actually use as an IDE than something that's designed to be a text-editor and then hacked into an IDE with plugins. This is just why I personally prefer an actual IDE, I still wouldn't tell anyone in my team to not use vim as an IDE if they like it.
|
|
#
¿
Apr 20, 2019 13:30
|
|
|
Subjunctive posted:Are you saying that VS Code is just designed to be a text editor? Or that you shouldn’t use plugins for IDEs? I’m a bit lost. Neither? I'm just saying that in general, using some basic backbone-software and bolting on a ton of functionality with plugins will result in worse UX than using purpose-built tools.
|
|
#
¿
Apr 20, 2019 14:22
|
|
|
Yeah I thought it was pretty clear that I wasn't ranting about modular design as an implementation detail (which the plugin system is for JetBrains) but rather about trying to force some software to be something completely different by using a bunch of unrelated plugins from a bunch of unrelated developers.
|
|
#
¿
Apr 22, 2019 17:45
|
|
|
Subjunctive posted:Isn’t most software composed of multiple systems built by unrelated developers? Why do you think that necessarily leads to more-likely-bad outcomes? Hey I just wanted to let you know that you're arguing against something I don't believe so I guess I'm sorry if I did a bad job of conveying my point in English
|
|
#
¿
Apr 22, 2019 18:24
|
|
|
Cuntpunch posted:Related: In discussing how he's solved the problem of shared state in his personal project - some game - he proudly tried to explain the plan was basically to dump all global state into, well, a big fat global object and just make sure nothing touched things they weren't supposed to. I'm not saying he wasn't an idiot, but are you sure he wasn't just talking about using entity component system architecture (which is a typical and good way of making games)? sunaurus fucked around with this message at 07:57 on Jun 14, 2019 |
|
#
¿
Jun 14, 2019 07:54
|
|
|
Xarn posted:This. Even trivial changes should always be reviewed. I know of a bank in my country where *everybody* had their remaining loan balances set to a specific amount for a while (until a rollback) because of a "trivial" one-liner sql migration that was supposed to only change a couple of values but was missing a WHERE clause.
|
|
#
¿
Jun 14, 2019 08:56
|
|
|
Keetron posted:I have no idea, and going to ask that question. I think it boils down to the usual downsides of a monolith combined with hip and new technology. The only good reason I've ever seen for microservices is being able to split up a large project between a bunch of small teams, because with normal tooling, it's much easier to have one team working on a small service than 10 teams working on a monolith. That's the usual downside of a monolith. Any arguments about how "microservices promote better code quality" are absolute bullshit in my experience, some of the worst code I've ever seen has been in microservice form. "More flexibility in scaling" is another argument I hear often, but I don't think this is really worth the overhead of maintaining multiple services for most teams, and if you really need more flexibility in scaling one or two parts of your monolith, just extract those parts instead of breaking your whole monolith into tons of microservices. This is the way I view microservices: each new microservice adds tons of overhead for deployment and maintenance but removes tons of overhead from having multiple teams working on the same project. If you're not splitting work between multiple teams, then all you're getting is the negative part.
|
|
#
¿
Jun 15, 2019 10:08
|
|
|
Protocol7 posted:No kidding. If only one of the tenets of agile development was to reflect on the process at regular intervals and implement constant revision where necessary... Uhh I don't see anything about constant revision in the enterprise agile manifesto
|
|
#
¿
Jun 25, 2019 17:30
|
|
|
When I joined my current team, the established practice was that whenever you commit, you ALWAYS amend to the first commit in your branch and force push. The goal was keeping a clean history, it seems they had never considered just squashing before merge. I guess it worked most of the time, because when reviewing code on gitlab, you can view diffs even between force pushes, but in my first few months working there, I saw people losing some work because of force pushing the wrong thing more times than I had ever seen it happen in all my previous teams put together. Thankfully, most of that work was recoverable. This also has created a weird culture in my team where PRs are kept really small, because people aren't used to splitting their work into separate logical commits. I agree that having a single mega-commit is hard to review, but in my opinion, spreading features over multiple tiny PRs which depend on each other is definitely not the correct alternative. Edit: Also, I told people to stop force pushing by default, and I now realized that one dev landed on a strategy of just making tens of commits with the exact same commit message, which is just the name of his branch. Haven't had a chance to talk to him about it yet. I guess it's nice that he's not force pushing anymore, though. sunaurus fucked around with this message at 17:42 on Jul 25, 2019 |
|
#
¿
Jul 25, 2019 17:36
|
|
|
You can give constructive criticism in a kind way. Just using "thumbs down" is essentially the same as saying "your idea is bad" without any further explanation, which will probably be considered mean by a lot of people, even if the criticism itself was valid.
|
|
#
¿
Jul 25, 2019 18:34
|
|
|
Queen Victorian posted:I’m in the final days at this job (already signed new offer and handed in resignation) so I’m just venting because this happens every loving sprint - I finish the goddamned thing with (usually) plenty of time, but no one reviews it in a timely fashion and I take the blame for not completing it, with my last full sprint at this company being no exception. If this ever happens to you again at another company, I think the best way to handle it is to just force your team to go more in depth during backlog grooming, and note down any implementation details that your team agrees upon in comments. The whole "using a library vs rolling our own" question should probably have been answered before you even assigned an estimate to the story. Man, I've spent about a year now in what I consider to be an actually agile team, and reading your post reminded me just how much I dislike scrum (which is what I was doing in two teams before my current one). I hope you have a better time in your next team. sunaurus fucked around with this message at 20:12 on Aug 14, 2019 |
|
#
¿
Aug 14, 2019 20:08
|
|
|
Pie Colony posted:What does this even mean? Client 1 - GET Client 2 - GET Client 1 - POST based on GET results Client 2 - POST based on GET results Client 2 overwrites Client 1's changes (even if they were completely unrelated to Client 2's changes)
|
|
#
¿
Aug 23, 2019 15:31
|
|
|
|
| # ¿ May 2, 2024 08:50 |
|
|
Walh Hara posted:I disagree, but perhaps we have a different understanding of what an enterprise architect is. Pretty much all of the questions you listed seem like they require development knowledge, though
|
|
#
¿
Jun 11, 2020 12:33
|
|