Liutauras Vilda

All we said was, what you asked about "better way of handling if and else" probably is the least problem you have.

There is a feeling that you have more serious problems with an underlying design, because by looking to code it is quite difficult to comprehend it.

Just out of curiosity, is it some "professional" application/system or some school assignment?

Jack Tauson wrote:I only want to create a new case request if case ID for the car doesn't exist in the database

Terminology is important, so the code is consistent, otherwise semantics can get off.

Jack Tauson wrote:sph.getAllOpenCaseRequestsFromDb()

Do you see how this code returns open requests? Why you'd want to create requests, don't you want to open them if they aren't yet?

@OP

And instead of having those low level code constructs, start with something higher level, example (you can have more creativity):
if (overrideTestingWithUserSelection) { for (CaseRequestHandler crh : sph.getAllOpenCaseRequestsFromDb()) { if (caseRequestNonCar(crh)) { cancelCaseRequest(crh); } else if (caseRequestNotOpened(crh)) { openCaseRequest(crh); } } }
Now people looking to your code would have a much better understanding of a logical flow.

private int tos;  // Top of the stack

1. rename variable to topOfTheStack or similar
2. remove now redundant comment explaining what the variable is

Stan Belen wrote:I'm thinking to tell my manager that I think that it would be helpful if the team can be divided into groups that are working in the same area and, in addition to the scrum, for these teams to have a separate meeting to discuss their work in more detail among each other. I think that this would make it much more helpful, to share how you are implementing something and bounce ideas, get feedback, etc.

Do you think this would be a good idea?

I'm not sure how your system/services are structured, but if you are saying something similar that Backend and Front-End teams are mangled, then yes, potentially would make sense to separate them.

Now, as far sharing knowledge or discussing the implementation details, give a try pairing with someone on the aforementioned task(s). Two heads usually are better than one. And that is also good for knowledge sharing.

Over the years observing those things in the teams I worked with, I feel your tasks aren't decomposed enough or in different words - too big in scope, hence could not be tackled in reasonable amount of time.

As an example what I mean, let's say you have a task to implement some API endpoint, that consists of (taking example from a thin air):

produce OpenAPI specs

create database table(s)

implement API specs

So now you have couple of choices, you can have a one task, or you can have three tasks, likely tackled in different sprints. So when you do this kind of repetitive work several times, you start getting a pretty good idea how long each of those tasks take. After few iterations like this if your team no longer sees the point in decomposing that much, you have it as a singular task, but now you can be more accurate in predicting the time it may take.

And I believe that any big task could be decomposed to smaller set of tasks, then those smaller tasks into more smaller tasks until they are manageable in terms of scope to achieve in a reasonable amount of time.

Another thing what I think helps, if you work on tasks and constantly get stuck on something that makes you delay in accomplishing them, maybe you don't do enough discovery around the area, so you have too many unknowns or fuzzy areas that surprise you during implementation.

So to deal with this kind of things, you maybe could have some discovery tasks prior actual implementation where you could give a go in some dirty way to get a sense what you are going to deal with and later just discard that work, so the upcoming sprint you could work on actual task implementation, but now with smaller chances to surprise you.

But you know, there is no one silver bullet, you need to experiment and see what works for you and your team.

Stan Belen wrote:The problem that I have is my JIRA Stories tend to keep moving to subsequent Sprints.

Well, either your stories/tasks are too big for the sprint to complete or you work too slow. Also clarify what is your definition of story? Asking this, because I saw in multiple occasions people use these interchangeable, say story, but mean task, and other way round.

The idea is, you shouldn't have tasks or stories that could not be completed within the sprint, and given (I'm assuming) you work as part of the team, before you get task into the sprint, you should get an agreement as a team that such task IS completable. Otherwise need to decompose them more, so they are smaller.

Anyway, have you discussed this with the team first? What they say? What your tech lead says?

A bit more on that.

If you are talking about university assignments, another general advice is, to read assignment instructions right away once you get them, so you could get an idea how much time you'll need to accomplish it.

If you have pretty good idea how long (approx) will it take for you, then you just start at the right time in order to finish on time

If after reading assignment instructions you don't have an idea how long will it take for you, then you start right away until you get better idea, then you see if you have a buffer of time and then you do whatever you want with that buffer

So that technique falls under "start earlier".

Other technique is do them "more efficiently".

Now, that can mean different things to different people. For me that used to be, do the things in undisturbed and undistracted environment. Meaning, TV off, phone off, snacks off until you make some tangible progress. The more progress you make in one go, the easier is to come back to task other time, because every time you have a clearer picture of the end goal.

Others may say, don't try to get everything perfect right away, get something working, adhering to requirements end-to-end, then as the time permits refactor/polish until you get closer to the perfect, and depending on time, you do what you can.

Start earlier or do them more efficiently. General advice, but you didn't ask anything specific.

Peter Ho wrote:---> The answer is -2 because the length first array is shorter than second one (5 - 3 = 2)

3 - 5 = -2

Carey Brown wrote:

Chris Smithtopher wrote:How do you manage things like packages, dependencies, and all that jazz?

...you should probably have already started your IDE learning curve before getting too deep into dependencies. Packages you should be able to do from the command line.

And so the dependencies, there are examples on those cert books how to set the classpath.

A one or two examples where class depends on few other to get it compiled and be able to run is a good start, and perhaps indeed don't need to dive significantly more, but just to get a sense what's happening.

Tim Holloway wrote:Eclipse is "slow and buggy"??? About the only bug I've been annoyed by is in the XML editor plugin and at least when it comes to start-up, IntelliJ wins the slow prize.

Tim, my experience is opposite. I stopped using Eclipse about 10 years go, one of the reasons being - very sluggish, couldn't smoothly handle couple of simple HelloWorld projects opened at the same time. And I remember hearing at that time people saying what you are saying about IntelliJ IDEA. I don't know if it is because of macOS (Mac OS X at that time), but IntelliJ IDEA for me was very smooth compared to Eclipse.

Then one other thing what used to annoy me, that Eclipse didn't have any reasonable "Search in project" functionality, so had to download plugin called something similar to "Quick Search", I think this, and then some other plugin for something else, and then someone advised to upgrade straight to Spring ToolSuite (STS), so IDE would meet minimal basic requirements for a day-to-day use, then everything become even more sluggish, and then I ditched it.

Even though IntelliJ IDEA is a great at recognising project structure and has no problems building projects after importing, I rarely building that way, like others said, like to use terminal for building <-- which by the way is also integrated into IDE whoever prefers that and not terminal natively bundled with OS.

I used git also extensively in terminal, but lately switched to IDEA's, the diff tool in particular is absolutely amazing, and I find myself being more comfortable that way. On the other hand, now there is a lot of other frameworks/plugins like oh-my-zsh for the terminal, which can vastly improve experience and integration with many tools on command line. Some tools are just better on command line, one of which these days couldn't live without is k9s. But this topic is just snowballs.

Tim Holloway wrote:IntelliJ has 3 project files, as I recall, each in XML format. One for the project itself, one for personal preferences, and I think the third contains current editing state (it has been a while since I looked). When committing to a source archive, the personal stuff should not commit, only the global project file.

Hm... it may depend on the project specifics and expectations you have. Our team never committed a single file that is under .idea dir and don't remember having a single problem. And that's not just one project, on many different projects, however, they are using either Maven or Gradle (if that's Java based project), and IntelliJ is capable of parsing those and replicating some of those you mentioned. IntelliJ also is quite good at recognising what plugins you may want to install when it scans the project based on the file types. But we don't have hard requirements on any 3rd party plugins.

But ok, your projects might be quite different. If there is something that requires some knowing, i.e. some remote debugging configs or so we normally write a small wiki, which I think potentially would reside in those IDE specific project settings. So yes, technically you are right, but can be avoided and not coupled with specific IDE files. And that's been the case for us, developers are free to use tools they are comfortable and want.

Tim Holloway wrote:Eclipse project meta-data differs considerably from what IntelliJ uses and likewise for NetBeans. So you cannot just suck an Eclipse project into IntelliJ or vice versa.

About metadata differences agree, but not sure about the rest. Those metadata files are specific to your local environment, not project in general. You should be able to import project to an IDE. Well, at least you can to the IDE (IntelliJ IDEA) I use.

A good example is CodeRanch's JForum, I saw some devs pushed some Eclipse config files, however, my IDE doesn't use them, and understand project by the build tool, i.e. Maven, Gradle. If these are not being used, you can still configure project with some manual input.

Steve Dyke wrote:This creates an infinite loop

Do you have an idea why would that happen?

Carey Brown wrote:For future reference:
Based on my casual observation it seems that Eclipse is the most preferred IDE though there are a couple of others.  In my 25 year career all of the companies I worked for used Eclipse.

That's not the case in my experience. However, I like companies which don't insist what tools to use, so you can choose whichever IDE you like.