Win a copy of Java Challengers this week in the Java in General forum!

Andrew Fielden

Greenhorn
+ Follow
since Jan 03, 2021
Cows and Likes
Cows
Total received
2
In last 30 days
0
Total given
0
Likes
Total received
3
Received in last 30 days
0
Total given
3
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Andrew Fielden

Fred Masen wrote:Hey Rob I am back with the go programming language  If you have some time, could you tell me where the bug is from my last program and post? I will appreciate. Thanks again.



Hi Fred,

I think the two languages (Go and Java) are very different, and they have different applications.
Java has over time evolved and had new features built in. It's a multi-purpose language with many different libraries and frameworks.
Go in comparison has much simpler language constructs, which IMO is a good thing as it's quite accessible to newcomers, and isn't bogged down with lots of syntactical baggage. It's also for situations where performance is a big issue as it's intended to be closer to the hardware. And of course Go does concurrency extremely well, and is without doubt the easiest language to manage multi-threading and thread synchronisation.

If you're concerned about the verbosity of your code, then a good IDE can help you a lot with auto-completion. I find that the support for Go in Visual Studio Code is excellent. It will even automatically add import statements, as Eclipse/Intellij does for Java.

2 months ago
Go
Ok, not just me then
I read a quote recently from some book I was reading. It said there are two types of projects - those that fail, and those that become legacy nightmares.
With the rate of technology change in this industry, things become out of date pretty fast. I think most of us have been on projects that are underpinned by ageing technology. You could view it as job security though - everyone's wanting to move on to the latest cool technology stack of the month. Someone's got to support those old systems.
2 months ago
I'm floating this question, because no kidding, in 4 out of my last 5 jobs, I've been put on a project out of the blocks that was either a total disaster area, didn't live up to the billing, or was not my desired technology.
2 of those I was point blank lied to at the interview, and led to believe I would be working on something else, or certain vital facts were not mentioned.

Software consultancies seem to be the worst for this. One job I turned up to, expecting to be working locally. On day one they told me I'd be going up to Leicester, which was not commutable from home so I had to stay in hotel accommodation for 4 months.
In that particular role I was a million miles away from my experience base of Java web development. Hell, my job title had Java in it so that was certainly not what I signed up for.

My point is that such projects are the ones that existing employees just don't want to work on, because they know that they're a complete shit show. New employees are like lambs to the slaughter. Cannon fodder if you will.

Now my strategy for dealing with this is to ask for another project. Failing that I'll definitely leave.
I just wondered how many people have encountered this phenomenon, and how common is it for a job to be 'not as billed'?
Have I just been unlucky?
2 months ago

Tim Holloway wrote:

Monica Shiralkar wrote:
However, when the old pro spends 5 hours thinking and planning and 2 hours coding whereas the new pro always look busy, the managers think that old pro has laid back attitude and is not doing that much hard work as rest of the team. This should ideally not happen but practically it happens often.



One of the biggest flaws in the human brain is its tendency to equate motion with productivity.

Given the world a choice between paying Brazil to let the Amazon forest basin sit undisturbed and operating as a global biological cleansing mechanism versus not paying and having Brazil clear-cut it down to another Sahara, it's very, very hard to get people to pay to "do nothing". To say nothing of in a more realistic model, too many people in Brazil wouldn't sit for leaving a resource unexploited where there are jobs and business it could generate in the short term as opposed to many generations.

So it is with software. Just about all of us have solved some of our stickiest problems not when we were "at work", but rather in bed at 3AM or in the shower. Sitting staring out the window isn't "working" and - my own biggest pet peeve - hours in chair is not productivity. Software isn't like hamburger where the more hours in the day you grind, the more software you get. Useful software, anyway. And even a hamburger grinder run overspeed outputs cooked meat, not actual hamburger.

COVID has done us a favor in that regard. It has demonstrated concretely that fighting your way through traffic to park in a chair at a desk for 8 hours or more a day isn't more essential to the economy than work-from-home in many cases.



You are the voice of reason Tim. I'd like to work with you. Any vacancies?

4 months ago

Tim Holloway wrote:Ageism.

I first faced static about my age in 1989. Then again, that was the worst employer I've ever had, bar none.

I actually missed the CORBA fad, although ironically I worked on a CORBA project for someone several years after CORBA had died out. Poor guy.

The point that HR departments (well, one of many points, ) miss is that while you might not have been taught the latest shiny technology in school - and actually, I don't recall specific technological platforms being class studies anyhow - what you have learned over time is often more valuable. Unlike the so-called "real world", computer people do learn from history, and while that doesn't mean that each new technology is inevitably closer to perfection (I present the warts in Java for example), it does mean that you have examples from the older stuff that you can leverage. Including having learned what actually works and what doesn't.

The trick, of course, is to recognize what's special about the new platform and not blindly try to force it to behave just like what you're used to. I knew someone who got frustrated trying to write Pascal like it was COBOL, Python has a different mindset than Java, and you wouldn't believe the number of people who check into the JavaServer Faces forum with "solutions" that attempt to program JSF like they're used to programming raw servlets - JSF is an Inversion of Control architecture and many people have a hard time wrapping their heads around the idea that the framework automatically delivers stuff to you rather than making you write code to go out and get it. Or that JSF is based on POJOs and that very little well-written JSF code is actually JSF-specific.

Anyone who wants the good old days where you were the person who was responsible for the COBOL payroll program on the mainframe and that's all you did until the day you retired on a pension is out of luck. I figure I'm likely to end up sucking up a new technology no less often than every 24 months, if that. Fortunately I enjoy that sort of thing.

The real problem isn't in old dogs learning new tricks, it's that Hiring looks for cheaper people who won't object to being forced to work insane hours. And most people who aren't young anymore have had enough of that.



Exactly. I like doing my job, but I also have a life outside it, and a family I want to spend time with.

Anyone who thinks that a culture of ageism doesn't exist in this industry, is deluded.

Btw, does anyone actually write bare metal servlets any more?! The choice of web frameworks these is absolutely bewildering.

And I take the points about experience being worth something. However, the hotshot kids these days think they know it all.

4 months ago

Chris Crawford wrote:
By the way, did you know that the 6502 opcode for loading a fixed byte into the accumulator is $A9? 😛



Haha. Vaguely, yes. My old Oric home computer had a 6502 processor. I think the BBC Micro did too.
4 months ago
Hi folks. I started my software development career many years ago (1989). Since then many things have changed, some technologies have come and gone.
I tend to think that there's about a 5 year sliding window of relevant knowledge in this industry. I mean, who cares that I know all about CORBA? Nobody that's who.

So for all my years of experience, I'm on a par, knowledge-wise, with people who graduated just a few years ago. Now, this can lead to potential bad feelings with discrepancies in salary. I personally think that everyone doing a similar job, should get paid roughly the same rate, but that's not how things tend to work. I get hired at a senior level because of my years of experience and age. Do I know more than the younger devs? Probably not, if you discount all that old useless tech. We are effectively equal when it comes to that 5 year sliding window of knowledge.

Don't know what my point is here really, or whether I'm just making an observation. I like my job as a software dev, and wouldn't want to do anything else. But I do feel like a lot of my knowledge/experience is wasted.
4 months ago

Simon Ritchie wrote:Hi everyone,

Next month I'll be starting in a new role as a mid-level Java developer with a successful startup.  The architecture is a microservices design, which is something I've a couple of years experience in thanks to a similar role I once had with a large multinational.  I'm keen to start well in the new role so I thought I'd ask some advice here.

What is the best way you've found to come up to speed on a new codebase?  Are there any tips or recommendations?  I've always found the first couple of months in a new role intimidating because, on top of all of the new technologies you've to become familiar with, you're also confronted with this massive codebase that's often difficult to understand.



Congratulations on the new job!

#1 tip I can give you, is to get involved in bug fixing. To start with you'll want to tackle fairly easy ones, but it does make you poke around the code and get a feel for how it's organised. This will help you familiarise yourself.

The other thing I can recommend is to understand the database schema. Most software systems are underpinned by a database. If you understand the data, it goes a long way to understanding the application code.

Good luck!
4 months ago