What to do if I am working on a language that I don't like [closed]

Question

I really don't know if this is the right place to ask this question, but if it isn't, then I guess someone will notify.

Anyway, I am working in a software development farm which is currently using PowerBuilder to develop a mid-size ERP solution. The work environment and company management are so great that it may be the best in the whole country. Only problem is the technology that are currently being used, which is this PowerBuilder.

Now I am a guy who tends to prefer modern development technologies, like DI containers, ORM, TDD, JQuery etc. PowerBuilder is a great tool too, but I couldn' like the application techniques used to build PB applications. These techniques are so inheritance-dependent that many a times these create a great deal of sufferings. I remember two days ago I had to change some processing logic in a core user object and as a result I had to test and re-test all the forms that the application have(apparently, there are almost 20 forms there, each of them with 3-4 kinds of functionalities). Also, learning PB is tough, because online material on this thing is very, very low. I can't afford to read all the documentation that PB provide because I have hard deadlines on the work that I have to do. Another thing with PB is that applications tend to rely on business logic that are implemented on databases which causes debugging to be a nightmare.

As a result, I don't feel motivated enough to work in this IDE/System/Framework (or whatever) anymore. My productivity has greatly decreased, and I am not delivering quality code.

I think I have the following options available to me -

1. Remain in the current job, keep delivering worse code and let my productivity decrease day by day, taking salaries and bonuses but not delivering quality codes/doing my job the way I should,
2. Search for a new job.

At this point number 2 seems a good option, but there are also some issues. As I mentioned before, our management may be the best in the country. Our company owner is himself a software developer with 24 years of experience in software development. He is currently our Team Leader and System Analyst. He is by far the greatest manager and boss I have ever seen. He understands developer's mentality very well(as he IS himself a developer). He is also a great, kind and generous guy. Our company is only a start-up company with 10 developers. Among them, only 3-4 people knows about the business logic behind the ERP, and I am one of them. If I switch my current job, it may hamper the development of this product which I really don't want.

I couldn't decide what to do in this situation, so I turned to the community for advice. Thanks guys for all of your suggestions.

Answer 1

Your boss took the attitude of, "Worse thing that can happen is I have to build it myself, so we have to do it in a language I understand." Happens to the best of them. He must have hired the rest of you because he wanted good programmers and not just those who can use PB.

You need to consider your other options. Working for people you like and respect is important. Cutting-edge technology is great, but working for an idiot is not. I know you don't like PowerBuilder and feel like you are not doing well, but your boss does and that is important. I don't think it will stay like this forever. After this experience, maybe you can convince him to do the next project in something else. He probably trusts his team a lot more now.

Personally, I would stay and talk to the boss about the future of the company, the technology and how they relate to what you need for your career. Keep your eyes open for a better job (always), but don't give up on this one.

Answer 2

With such an experienced boss that you clearly look up to, have you considered talking to him about your concerns about the tooling? It may well be that you just need a mentor to show you how to do things efficiently, by knowing the tricks and the things that don't work.

Also, a good craftsman can still do a reasonable job with inadequate tools.

Answer 3

If you dive into (learn deeply) a programming language, you will find more fun than you expect.

It seems current company is so nice that you cannot take a risk to leave it. If you stay the company, you have to use PB. You could choose to increase interest on PB. If you are good at something, you will like it.

By the way, something as TDD is sort of development methodology, you could try using them in PB. Sorry I don't use PB so far, cannot say more about PB.

EDIT: Limited PB resource is same to every developers, so if you are better than other PB developers, it's ENOUGH. Deadline is not dead if even you such a qualified PB developer cannot finish it:)

Answer 4

There must be a reason why the boss decided to use PowerBuilder for that project. Either he is ignorant to more modern technologies, or he has good reasons and maybe you are not using the tool appropriately. If he is ignorant, you could try to convince him to use a state-of-the-art technology or look for another job; in the other case, ask him to show you how to do it better.

Answer 5

Different languages and tools have different patterns and techniques that they require for effective use. Your boss has been using PB effectively, so he must have patterns and techniques that work well for him. The problem may be that he's not able to tell you how he's able to use PB effectively.

The best way to proceed may be another pair-programming session, but you need to sit at the keyboard instead of your boss, and have him guide you. As you work, make sure you understand the reason behind all of the steps. If there's anything you have questions about, interrupt him. Don't worry about slowing down productivity; that's not the goal of this session. What you want is to transfer as many of the patterns and techniques from his head to yours as possible.

Answer 6

Sayem, I feel like I know you because I've communicated with you on StackOverflow before. In fact, I deal with the same situation you deal with, in that everywhere I've gone they have PB. And like you, I've wanted to broaden my language exposure but have struggled to do so.

A Comment about PB

But the issue isn't PB, the issue is legacy PB. I don't know how old your code base is, but in about 100% of the PB apps I've seen, none of them used OO they way they should have. They were all hacked together with procedural language techniques. It's not that you can't do test driven development in PB, it's that the testing hasn't been easily integrated into the IDE and wasn't a part of that product's development foundation. It's understandable, because when PB was made, TDD and even agile techniques hadn't been invented or weren't common yet. PB is not the only tool that has this problem.

However, if I had to build something reasonably fast that needed to hit a database, using PB would not be my excuse for low productivity. Inexperience with PB, or any tool, can be an issue, but not PB. Also, you seem concerned about inheritance, but you'll find inheritance in other languages too. Again, in this case, it seems the inheritance framework that was created wasn't designed with a great deal of forethought, and that's a problem with the way the app is built, not with the OO concept of inheritance.

Where I agree with you is that PB's third-party support lags behind the competition. Like you, I've looked across the hall at .Net development teams that seem to have an endless and mostly free supply of third-party tools at their disposal, from ER frameworks to simple utilities, not to mention about a hundreds books and forums.

How to Change a Tech Stack

Now on to your question. How do you get into a new technology stack? Like some others have said, if your company is dead set on a given technology and has no interest in moving on, you might have to leave.

Leaving

First, build some knowledge on the side. It's hard to move to a different tech if you have no experience. HR drones will look at your resume and see that there isn't any Java or whatever on it, and throw it out. You could also just lie on the resume...some people do that, and if the interviewers aren't technically strong, then you might find a place you can get in.

The other thing is to use your network. I am still doing PB, but switched to a job that was in a new business domain. I am having to learn a lot fast, but not having to struggle with the technology is nice. The product I'm supporting now is moving to .Net and that's a transition path that plays nicely into what I wanted to do. I got this opportunity through a contact that was able to vouch for my diligence and work ethic. I'd probably not have gotten it without that endorsement.

Staying

As Jeff O said in his post, there are some good reasons for staying and one of the big ones is having a good boss. Another is having a good team. That's not to say you couldn't get a good boss and team elsewhere, but they are reasonable reasons to stay.

If you can't get the technology to change and you decide to stay, I can only think of a couple things.

• Commit to being an expert. It really sounds like you're not motivated but you have to find a way to become motivated. Don't complain that reading the humongous documentation takes time. Find a way to learn it. It could be worse, there might not be any documentation. As you build expertise, your productivity will improve. It'll improve anyway if you commit to staying and keep building experience. And keep refactoring the code, that will bring gradual improvement into the code base that may help with some of your frustrations.
• If you really just can't stand it, then don't give extra to the company. Do a good job, but in your free time instead of improving your PB skills, do your own projects in the other languages, or get involved in open source.
• Move to a different position in the company. Management, project management, business analysis, testing, sales engineer. In fact, you seem to have a good rapport with your boss. If you can convince him to let you be the system testing architect, then you can introduce TDD to your company and be a force behind changing the code base to support test harnesses. However, this would be a difficult task and I doubt most business managers would want to invest that kind of time and money into it.

Whether leaving or staying, there will be some extra investment on your part to make changes. One last comment: if you are truly unhappy and feel that the technology is the focal point of this, then go ahead and move on. Given some of the issues with legacy PB code and the dwindling number of new PB projects, I can understand your wanting to make changes. But if you are basing your happiness on a tool, understand that it won't be long before another tool comes along that's better and you might find yourself looking again.

Answer 7

It may not be an option, but have you explored the possibility of using an alternative IDE for your work? I imagine that whatever minor interoperability problems might arise would be but small penance for you to pay to be able to work in the environment of your choice. By that I mean, you might have to jump through more hoops to check your work into and out of source control, because it isn't integrated with your alternative development environment. But if you otherwise got to spend most of your day in the software of your choice, you would probably be willing to take on the extra work.

For example, I see no reason why a developer working in a shop that primarily used Visual Studio for C++ development wouldn't be able to install Eclipse and use that instead, if she preferred.

I've even heard stories about a few renegade individuals who can't stand the idea of using an IDE for development at all. Lore has it that they write entire, enterprise-level projects in something like Notepad++. I doubt that has much effect on the rest of the team, as long as they produce quality code.

Answer 8

I had this same situation, in which changing the technology used was not an option (dictated by client).

If you feel it hitting your morale, or team morale, and it can't be changed/isn't going to get any better - get out while you can. I wish I had.

Answer 9

Our company has been using powerbuilder for two decades. Recently we looked into powerbuilder.net. It might be worth a look.

Plus if you start new projects or internal tools you can try to convince your boss to use the newest technologies.

Answer 10

It seems the issue is not whether PB is a good tool or not, but your lack of motivation and mindset. Sometimes as developer you are confronted with things and situations that are not that appealing but as a professional, you need to make the best of the situation.

In my opinion there is always something to learn from each environment and language and PB is no different, for instance they have the concept of data window which until this day, is a very powerful concept. I am not trying to sell PB in any way (even though at one time I worked on the compiler) but as a piece advice you need to start thinking beyond tools and think about the goal. To produce software.

Answer 11

I think, you can try to convince your boss to do a pilot project with the latest technology stack you(and may be your other colleagues) are familiar with. If you can make him happy with that project, you may expect to have a shift to that technology later. And as you are having hard deadlines, you may consider to do the pilot project in your own spare time, not in office hours.

Answer 12

Lets divide it to 3 problems.
1. Learning Curve
2. Technology
3. Management

Learning Curve
In technology that i known(C++,C#), if you need to resolve non-usual task. You will find yourself in same problem like yours : no info on the web + hard to understand API.

Technology
The PB supporting call from external dll, so each tasks that other language use better then PB, you can call it from dll.

Management
Management that deciding what exactly technology to use, can't be defined as best management in the town :).
Management must want an results, and see your development as black-box.
(Of-course management must decide large scale decisions (in technology too))