My new job is about 75% proprietary software - Should I be worried?

Question

So this is my second job out of college. Job 1 was at a team doing embedded software, so I did a lot of C, Javascript, HTML, CSS, and some Python and Java. This new job mentioned Java during the interview process, but I'm coming to realize that the majority of what I do will be in a proprietary language that isn't fully real coding, but more going into object in a user interface and customizing them. It isn't using a document to code, but rather their own tools that auto generate HTML/Javascript/CSS with statements you write. However, some of the sprints (it's a SCRUM team) do work on the core engine in Java, and I know the last three sprints were all in Java but I'm not sure how often that happens.

How dangerous is this for my career? I don't know if I want to be an engineer long term or go into management, and at my first job I really enjoyed the Java and Python parts of the job so the reason I moved was for more exposure to that, but I'm not sure I'll be getting that much here. I'm also doing a part-time online master's, so while here I will still be studying on the side as well.

I also really like my team, the pay is decent, and the location is good. This part of it is really my one big concern that's making me really anxious.

Edit: I'm worried about how it will look if I leave in 3-5 years, pending if I'll still even be employable at that point. I did forget to mention, most of the development is test-driven, and the testing tool for the platform isn't done yet so we are creating JUnits to test all our code. In a way, I will still be using Java and learning Java 8 for JUnits and once in awhile to work on the engine itself. I can highlight those parts of it, but I'm just worried about going in a wrong direction that makes me less competitive compared to others in the job market.

Answer 1

the majority of what I do will be in a proprietary language that isn't fully real coding, but more going into object in a user interface and customizing them. It isn't using a document to code, but rather their own tools that auto generate HTML/Javascript/CSS with statements you write.

This is probably very bad for a career in software development. This sounds like a cousin of using dreamweaver or something like that to build a website; when that was a job market, it was largely taken up by technically-inclined non-technical people if you get what I mean.

As an engineer who interviews other engineers, I would not consider this type of work to be experience in software development. That doesn't mean there can't be careers for these kinds of jobs (I don't personally know) but this is not likely to be considered valuable experience for a career in software development.

Answer 2

Regardless of what you want your career to be in, a good skill to have is being able to look for the opportunity to learn and grow in any situation. Regardless of the specific tasks you're doing in this current role, you still (pretty much always) have a chance to improve yourself in a way that will look attractive to future employers.

In other words, to answer your question: Instead of wondering how badly a future employer will think of the work you're doing, look for ways that this can help you improve.

Writing pseudo-code in a tool that (eventually) generates software isn't - in the literal sense - experience in traditional software development. However, it can be a valuable exercise for a software developer, for a number of reasons:

1. It teaches you to think about how inputs affect outputs. Software is generally a process tool - it takes some input, and generates some output. By entering your commands in this proprietary tool, and examining the code it generates, you're getting a new perspective on how software can interact with inputs and outputs.
2. Since you've stated that you're getting some experience writing the tool itself, you've got another great learning opportunity: writing a piece of software that writes code forces you to think really hard about what makes good code. Since you're not writing the (actual) code output yourself, but rather writing a tool that generates it, you're basically writing a "software developer" as a piece of software: what better way to learn about doing something, than to write software that does that thing?

In addition, there's a whole different factor here: Literally writing software isn't the only possible career choice you could make. There are all kinds of jobs that are closely related, but which lean very heavily on the exact scenario you're discussing - using software-ish skills to configure/extend/modify off the shelf applications - ie being a "Salesforce Developer" or "Sharepoint Developer" or "ERP Implementer" and so on. Often, these roles are in very high demand, since they require someone who can think in terms of manipulating a tool that results in software, versus directly writing software. (added this paragraph in response to a comment below).

So: if you like the job, and you like the employer, and you feel like you're contributing and learning, be prepared to show those contributions and what you've learned in the future context of looking for your next job. Instead of being worried about how it will look, take action to learn from this role, and show off what you learned.

Answer 3

It isn't dangerous to your career at all. Imagine you were using the latest cutting edge JavaScript (or whatever) framework instead. In two years everyone will have moved onto to something even newer and forgotten that one even existed. That is just the nature of the industry. So was that experience wasted? Most people would say it still counts.

I don't want to sound condescending but you say you are still inexperienced so I will reveal to you the truth that many full-time professional programmers only spend half their time programming anyway. The actual programming time diminishes the more senior you become. More time is spent in meetings, doing planning and gathering requirements, working on documentation and a whole heap of other tasks. If you find the programming you are doing easy then take the opportunity to learn more about the problem domain you are working in, the business, the other non-coding aspects of working in the industry and if you are really desperate to code, do some open source on the side and include a link to your Gitlab (or whatever) on your CV. That's even better in some ways, because you can actually show it to people.

Really, you have nothing to worry about. If you like your conditions and your cow-orkers and location, count yourself blessed, take the opportunities you have to round out your skills and devote your spare intellectual capacity to your studies and your personal projects. You will be fine.

Answer 4

As mentioned dbeer's answer, the type of task is not really optimal for future jobs and spinning it in a good way will be hard.

I also had a job working with an obscure language (RTE) even within the domain (B2B messaging/EDI). But the way I described it was through the language it is built upon (standard C, customized for the domain - extremely high volumes of small and identically structured documents), which was far more helpful for the interviewers to understand.

Since those days, I have worked longer on more "traditional" languages, so I usually just mention the RTE development in a short sentence.