I've brought my company's JavaEE 7 web application through NetBeans' upgrade life cycle, starting at NetBeans 8 I think. 10 or so years ago. NetBeans was great, when I first started, around version 8 or 9 - almost every "EE" feature worked. The years during transition to Jakarta were rough, most EE features lost.
However during this time I've learned a lot more about java as IDE "magic" was mostly gone. (Converting ant to gradle, better understanding of dependency management, jaxws wsdl generation, better understanding of the deployment and application container, probably more...)
I'll probably upgrade to 25 soon. Now-a-days there's never any problems when I upgrade, I guess because I'm no longer reliant on any IDE feature. At this point NetBeans is just a text editor with remote debugging capability. I enjoy it.
Well before AI, us old guys had to google our own issues and copy/paste from stackoverflow. When I was a junior I never thought about being overly reliant on "google or stackoverflow", but LLMs are slightly different. I guess it would be like if I googled something and always trusted the first result. Maybe for your question it means not copying/pasting immediately what the LLM gives you and have it explain. Wasting a few mins on asking the LLM to explain, for the sake of learning, still beats the amount of time I used to waste scanning google results.
If you're a reasonably well-performing IC at US big tech, your "boss" is often also a grunt with little real control over your salary. Just a different flavor grunt from you. In my experience, these managers are often happy to throw money at you but don't have much latitude to do so. Having a competing offer gives THEM leverage to try to convince those guarding the money hose to open the faucet a little.
Yes! I've done it several times. It's one of the best and most reliable ways to get a raise.
It's "business." Your manager isn't going to make a counteroffer, then wait a month and fire you. I mean, they might if they're a total D.bag, but I've not yet had that experience. And if I had, I'd already proven to myself and my manager that I could get a higher-paying job elsewhere. It'd be a minor annoyance on my side.
I don't want to give away specifics, so take these numbers with a lump of salt; the ratios are correct:
Went from $50k/yr [1]-> $80k/yr [2]-> $120k/yr [3]-> $205k/yr
[1] The company wanted me to stay and raised my pay to match the competing offers.
[2] The company wanted me to stay and raised my pay to match the competing offers.
[3] The company didn't want to pay that much, so I put in my two weeks and moved to a different company.
From my experience, I've found that requesting a raise without a competing offer often leads to a small or no increase in pay. However, when I've approached my manager with a better offer in hand, it has consistently resulted in substantial pay raises.
Why? You proved you're competent to the potential suitor by obtaining an offer. They got some valuable quality candidate interviewing experience which can be difficult to achieve, and you got a rock solid tangible improvement in your work QoL, even if the target ultimately didn't achieve their hopeful hire. Possibly they got some data that (to them) implies they should have offered more money. Win win. I would say a win for all of us because "more money".
Sure, I guess you could play it back and forth like your sibling comment implies, that seems risky though (you might end up with no offers).
Also why do I want to stay with the cheap people? They proved to be unable to deliver market rates for my efforts unless I make a big scene about it. I don't like to do business with people like that.
There might be other factors at play, though. Like one company I stayed at for a while was only a lovely 45 mins walk from my house, and that was excellent for my mental health every morning and afternoon. Trading that for an hour in the car would mean I'd want more to offset it.
Why? Everything is a negotiation and you're not wasting their time.
It's no different than price shopping between mechanics. You can do that while being clear on your intentions and not making any promises you can't keep
It depends on the counter offer and your situation. I would have agreed with you, but a couple years ago I told my employer that I had a job offer kind of land in my lap (I wasn't actively looking), that it was good and I was inclined to take it. I wasn't unhappy at my current job, but the change in title/seniority and compensation of the job offer was definitely worth it. They didn't want me to leave, so they countered with a very strong offer, which I decided to take and stay with the company. If you want to leave because you're unhappy with other aspects of your job, then I agree that accepting a counter offer doesn't seem like a great choice.
That is literally how I got my last promotion. I set up a meeting and told them I had an offer I intended to take. They had a 20% raise and promotion approved within 24 hours.
I also routinely get asked by managers for promo recommendations for coworkers thinking about leaving. IF they refuse to counter, then you should be asking yourself why you are staying.
You cant pull this maneuver more than once or twice, but it lets them know you are serious and wont just whine and accept token raises in future negotiations.
This is cool. Narration of audio books is a time consuming process! I agree with some of these comments here about how AI narration can sound robotic though and may not be too pleasant to listen to.
However, for anyone who is, or knows a family member/friend with a certified disability, or is a veteran, there is a free program to listen to a vast collection of audio books (with real narration) provided by the US Government. Check out https://www.loc.gov/nls/ (Braille material too!)
>I agree with some of these comments here about how AI narration can sound robotic though and may not be too pleasant to listen to.
I have encountered readers on librivox with such terrible pronunciation that following the story was rather difficult. on the other hand, a robotic voice could work well on some cyberpunk material
In reality I know what you mean, but not a good look for you imo. Imagine that upgrade causes an issue upstream and someone has to explain who approved it. There's always a way to get housekeeping items approved, sneaking it in isn't it.
I agree, it was a calculated risk. Without getting into the deets I was confident it wouldn’t introduce any major issues. In fact NOT upgrading had resulted in problems that affected production a few weeks prior. Would I recommend a junior engineer yolo it? Of course not. But I’d also warn junior engineers to always keep a healthy skepticism when they are told “No, this cannot be done.”
> There’s always a way to get housekeeping items approved…
Yes, at a functional software shop, upgrades and maintenance are not considered stretch items. I did my best to make the case from a technical (bug fixes and features), business (vendor X won’t support us on this version), and customer (customer wouldn’t be happy if they knew we were running version X) standpoint. However, at a dysfunctional software shop, none of those factors matter (or they don’t matter as much).
> I did my best to make the case from a technical (bug fixes and features), business (vendor X won’t support us on this version), and customer (customer wouldn’t be happy if they knew we were running version X) standpoint.
All I know is government contracts, but I've been pretty successful at estimations. Much like the top posts in this thread, none of it is for free. Most of the time requirements come in a few sentences, maybe a paragraph, rare cases a document. There's no estimation until the requirements are flushed out in some type of use case which has some bearing on the technical constraints of the system. (The client pays for this, and provides feedback.) The next step is planning, which is where estimation comes from. (The client pays for this.) In terms of planning I do strive for maximum 16 hour chunks which helps accuracy. For estimations that I have low confidence in, I'll have conditional chunks that may be used. All of this is transparent to the client.
If the client asks for an estimation before the above steps it's known by everyone that it has no official meaning, because everyone is aware of the above process.
How does this generally work? I've played with openai's API and I can send it questions and get answers. Is this app just parsing new additions to commits and passing in the whole code block as a prompt, with an additional line saying "please review this code"?
Additionally, how is this app able to handle so many potential requests to openai? Are they already paying for a bunch of tokens in anticipation? Or do you pay for how many tokens used per month? (The openai pricing is a little confusing since there's so much you can do.)
The goal is to provide more context to the model and use the changes with the title and description of the PR to get a review, while asking for improvements and suggestions.
This is harder than it seems. The way we are doing with Robin (Reviewpad's AI Reviewer) is by feeding it context about the PR and results from our static analysers and allowing the developer to prompt directly through the PR comment. For example, https://github.com/marcelosousa/robin-preview/pull/2
No need to be so harsh, they're not proclaiming anything just explaining their routine.
I agree though that testing the feature branch on the develop branch is not the same thing as that feature branch living in main, because some other feature branch in develop branch may be indirectly affecting the original feature branch.
No joke, "C for Dummies" - it's more teaching you CS101 concepts, less about "C". Tons of examples to go through and the attitude of the author is very helpful compared to a lot of other styles out there.
I was failing my computer science classes first semester. Towards the end of the semester I sat down in the library for a few days and just went page by page typing every example and compiling it. Aced every IT class I had the next few years. I attribute that book to making everything "click" for me.
Once you understand the beginner concepts that book shows, then you as an individual would know where to look to gain improvement.
However during this time I've learned a lot more about java as IDE "magic" was mostly gone. (Converting ant to gradle, better understanding of dependency management, jaxws wsdl generation, better understanding of the deployment and application container, probably more...)
I'll probably upgrade to 25 soon. Now-a-days there's never any problems when I upgrade, I guess because I'm no longer reliant on any IDE feature. At this point NetBeans is just a text editor with remote debugging capability. I enjoy it.