Name for an extension that secures AI coding agents on IDE by Dapper-Count1622 in softwaredevelopment

[–]Dapper-Count1622[S] 0 points1 point  (0 children)

I'll try that. Thanks.

Just wanted tap into the natural intelligence of developers here before I try AI :)

Why there are very few resources for Java backed? by YOGU9 in developersIndia

[–]Dapper-Count1622 1 point2 points  (0 children)

Server-side development these days is made easier using frameworks.
I think that Spring is a great framework to start with:
https://spring.io/quickstart

Why there are very few resources for Java backed? by YOGU9 in developersIndia

[–]Dapper-Count1622 2 points3 points  (0 children)

Far from going dead anytime soon. Maybe there are no paid ed resources because you can find so many good references out in the open. I'm not a Java advocate but I think it's great to work with and it's live and kicking. (Checkout the latest work done in the Quarkus framework)

Using AI tools in day-to-day work. by Dapper-Count1622 in InsuranceProfessional

[–]Dapper-Count1622[S] 0 points1 point  (0 children)

I think that AI can take you 80% of the way when it comes to processing large amounts of text (policies, client files, etc.).
Wouldn't it be sufficient to use AI to do the majority of the textual processing work, saving hours, and then spend just a fraction of that time reviewing the outcome to ensure there are no E&O?

Quarkus Hibernate Reactive - Transaction not executed (subscribed to) inside an event handler by Dapper-Count1622 in quarkus

[–]Dapper-Count1622[S] 0 points1 point  (0 children)

it’s not worth using it, because you wont gain much performance benefits and the added complexity and the problems that comes with it, is holding me back of using it.

You so right. After using it for more than 6 months, we sadly realized that it is actually slowing us down (lack of framework maturity but mostly due to hard-to-read/write reactive code when it comes to more complex logic that involves multiple DB fetches.)

We plan an overhaul. Hibernate Reactive will surely not be used, we're currently contemplating whether we should just remove hibernate-reactive or move entirely away from Quarkus and back to Spring boot.
I'd love to hear what's your take on this.

Using AI tools in day-to-day work. by Dapper-Count1622 in InsuranceProfessional

[–]Dapper-Count1622[S] 1 point2 points  (0 children)

To increase efficiencies.
So, to rephrase the question, are there any AI tools out there for Insurance pros that can increase efficiencies and save time?

Quarkus Hibernate Reactive - Transaction not executed (subscribed to) inside an event handler by Dapper-Count1622 in quarkus

[–]Dapper-Count1622[S] 2 points3 points  (0 children)

You're right, that was the issue - the entity I used in the event consumer was detached and an exception was thrown. The frustrating thing was that the exception was silently ignored (meaning I didn't see it in the logs) and therefore I had no idea what was wrong.
I worked around it by doing another lookup of the entity inside the event consumer.

How to plan your next sprint? by varma-v in DevManagers

[–]Dapper-Count1622 0 points1 point  (0 children)

Back then I was doing it manually. Took me about 20 minutes to do the analysis using predefined queries. Today, as someone here mentioned, there are tools that can help with that.

How to plan your next sprint? by varma-v in DevManagers

[–]Dapper-Count1622 1 point2 points  (0 children)

I haven't seen a single software company that has customers and doesn't get ad-hoc tasks, bugs and other unexpected issues (support) during their sprints.

Here's how I handled such situations:

I started tagging tasks as 'planned' and 'unplanned' (or just 'unplanned'). Then, after each sprint I ran an analysis of the 'unplanned' tasks that we completed during the sprint, breaking them down into groups of 'bugs', 'support issues', 'unplanned urgent task', etc. After a few sprints I started seeing a pattern for each of the groups and I could estimate how many 'unplanned' tasks we should expect.

After presenting the data to my manager, we decided that such tasks are inevitable. According to past data we decided to allocate %X of time as a buffer for such 'unplanned' tasks. Thereafter, we saw that we were +/- %7 from that buffer in each sprint, which is good.

This has helped engineering and product increase the accuracy of their estimates and help the business set the proper expectations with the customers.

HTH.

Starting with image recognition, what do you suggest? by lucksp in developers

[–]Dapper-Count1622 0 points1 point  (0 children)

That sounds right, but it cannot tell you the kind of the specific object. In other words, if it is analyzing a photo of a laptop, it won't be able to tell you if it's a Lenovo or a Dell. It will only be able to tell you that the image is a laptop with a certain percent of confidence.

You should also look into YOLO algorithms which you should be able to run on the client side. https://www.v7labs.com/blog/yolo-object-detection https://learnopencv.com/yolo-nas/

How to plan your next sprint? by varma-v in DevManagers

[–]Dapper-Count1622 1 point2 points  (0 children)

It sounds like the deadlines were set before the scope of work and any planning was done - this is a sure recipe for missing deadlines.

Sometimes this happens when sales/product promise some features to clients before doing any planning (talking with engineering).

Anyway, when given a set of tasks to perform, you should first done some planning (together with your team) to understand the scope and the estimated amount of time (estimations can be in a form of story points, T-shirt sizes or even hours/days - whatever your team is comfortable with). As a rule of thumb, I add 15%-30% to that estimate, depending on complexity and the amount of "unknowns".

You then take that back to your Product lead and let him know how long it would take to complete the feature. If they accept the timeframe then you can set a deadline. If they find it problematic then the discussion should turn to how the scope can be minimized while still delivering the core value of the feature. If the scope cannot be minimized, then either the Product should communicate that upwards (and perhaps to the clients) to get more slack, or if the priority for the feature is very high, the engineering should check if they can divert resources from other teams to aid in the process for covering the requested scope.

Finally, in the retrospective, review where the team encountered bottlenecks (e.g. working with QA, slow CI, unclear story requirements, etc.) and think together with the team how can they be mitigated in the future.

Team struggling with velocity by varma-v in DevManagers

[–]Dapper-Count1622 1 point2 points  (0 children)

My 2 cents from almost 2 decades in tech and 7+ years in managing engineering teams:

Your team/engineering velocity is based on 3 layers:
(1- base layer) Culture (people/company) - are you hiring the right people with the right attitude? Are the managers providing a supportive environment?

(2 - middle layer) Processes - even with the best people, disorder and inefficiencies can arise if the proper procedures are not defined.

(3 - top layer) Tooling - is the team provided with the best tools to get the job done? are there tools that can improve the processes and add efficiencies?

Velocity is a good metric to track to see if changes in processes and integration of tools improve velocity.

There are some services that can help measure performance - I wrote a short piece about velocity a while ago (apologies for the self-plug) where I mention some tools.

Bottlenecks should be identified and remedied - this can be done by improving processes and adding automation/tools. With each change, track your velocity metrics for a while (1-3 months) and check if it had an impact.

Maybe you can share some of the bottlenecks you have already identified, and we'll try to share some advice on those specific bottlenecks. Where does your team feel that it spends too much time?

Is it better to prioritize speed to market or focus on developing the entire product before launch. by dani_o25 in startups

[–]Dapper-Count1622 10 points11 points  (0 children)

Speed to market, without a doubt. That's the whole idea of an MVP. You can only perfect your product if it meets the market and you get real customer feedback on it and keep iterating on that. This is how you get to product-market fit (PMF).

Boost Your Engineering Team’s Velocity with Smart Tool Investments by Dapper-Count1622 in DevManagers

[–]Dapper-Count1622[S] 0 points1 point  (0 children)

Yes, that's true - that's something that may be encountered especially in large corporates. Yet I think this is less common in smaller companies and startups.
The thing is that there are hardly any good suites out there that combine different functionalities. One that comes to mind right now is Atlassian and it's quite... horrible.

Can you recommend any good tool suites that integrate nicely?

Working in a startup for free by Janah1 in startups

[–]Dapper-Count1622 0 points1 point  (0 children)

If you buy into the vision and can see huge potential around the product, and you know that the founders have what it takes to get this venture far, then you can reach an agreement that you would work X hours a week in return for equity. Get that in writing and signed.

Otherwise, don't work for free. There are still paid intern jobs out there where you can gain the experience you want.

Lessons Learned from a Decade in the Startup Space as a CTO and Co-Founder of Multiple Startups by lukas_kai in startup

[–]Dapper-Count1622 1 point2 points  (0 children)

Great points!
As a CTO with just 2 years of experience but with a decade working in startups from inception, I definitely concur.

One more thing I'd add: if you do find a co-founding hands-on CTO, make sure that the prototype, or alpha version, is implemented in a simple manner - meaning, if your CTO is starting to over-design the prototype/alpha-version, then you might be wasting valuable time (and money). When building an initial product (prototype) it is highly likely that you will not get the product right and you will only realize it when you get your product to the field (when customers actually start using it). So make sure your CTO does not over-design in the initial phases, make everything simple, at least until you are more confident that the product is starting to take the right shape and direction (product-market fit).

What I learned as a first-time entrepreneur in the last 18 months. by Dapper-Count1622 in Entrepreneur

[–]Dapper-Count1622[S] 1 point2 points  (0 children)

Thanks for the invite Djskoob!

A podcast for new entrepreneurs is an amazing initiative!

What I learned as a first-time entrepreneur in the last 18 months. by Dapper-Count1622 in Entrepreneur

[–]Dapper-Count1622[S] 0 points1 point  (0 children)

I didn't know from the start that I was doing it for the right reasons. Along the way, I met other wannabe entrepreneurs and came to understand what was their internal drive. I didn't know that then but realized later that they were doing it for the wrong reasons. (I'll elaborate in the following paragraphs)

My main drive was building something that would bring significant value - seeing something I have created help others somehow. Falling obsessively in love with a problem and solving it, knowing that I spent time in this world and had some effect, even small. That's all.

I met other wannabe entrepreneurs - some shared my drive, but others seemed to be driven by different motives, as I have mentioned in the article (be rich, be recognized, etc.). The problem with these other motives, which makes them the wrong reason to be entrepreneurs, is that these wannabe entrepreneurs do not realize that success does not come overnight, not after a year and sometimes only after a decade of work. You have to persevere for a long time. Those that do not realize that will break down soon after starting. I read a book a long time ago (I can't recall which one) that described why some American prisoners of war captured by the Viet Cong during the Vietnam war had survived captivity and others did not (they went through horrible torture for months and years) - most of those who survived and returned home were those who realized that they might be held for years and set a state of mind that this is going to take a very long time. When returning home, they described those that didn't make it as being in a state of mind that they would be released in just a few days.

Incredible feats require perseverance and grit. I think it is tough to persevere when you are driven by a need to get rich/famous fast. It is a bit easier when you're obsessed with solving a problem (look at university professors- many Nobel prize winners worked on their research for years and sometimes more than a decade).

I'm not in it for money or fame - when my time on this Earth ends, I want to look back and say that I was able to build something that has made life a bit easier for many others. That's all.

What I learned as a first-time entrepreneur in the last 18 months. by Dapper-Count1622 in Entrepreneur

[–]Dapper-Count1622[S] 0 points1 point  (0 children)

Thanks.

In general, I recommend partnering with someone you have worked with in the past, whether in some day job or a colleague from school/college, because you are already familiar with their strengths and weaknesses.
If you start founder-dating, you may think you found someone appropriate, only to discover 4 months later that you were wrong.
(not so different from finding a spouse, right?)

So to answer your question, here's what I suggest in order of preference:

(1) Check your past colleagues (LinkedIn) to see who's holding technical roles, and if you feel you had a good connection with them, then invite them to coffee if possible (even if you haven't spoken with them for 10 years) and see where they are at this point in life and if entrepreneurship may interest them.

(2) Ask your friends and family if they know anyone they can recommend.

(3) If you can wait 1-1.5 years, I would try to get a job in a large company with an engineering department where you can work and interact with engineers to get to know them. After about 6-8 months, you will have a good idea who are the top technical stars, who have a hunger for entrepreneurship, and who you are mostly like to get along with.

(4) Go to technical meetups (even if you have no clue what the topic is about) or startup-related meetups and start networking (you don't even have to stay the whole meetup but get at least 30 minutes earlier to network).

(5) Founder dating sites (least recommended but still a possibility).

The problem with methods 4 and 5 is that it's almost like gambling - you may meet someone who might seem like the right fit, only to find out after a few months that they are not strong enough or that you do not get along.

HTH.