6

I really enjoy the actual programming part of programming, and actually writing the code, and figuring it out. But on this project I've been working on, most of my time has been spent on kind stupid stuff (trying to run a Java program in the background (I swear javaw does the same thing as java) and trying to put a jar in a jar, and looking at alternative methods for both of these).

I feel like I do this on a lot of projects, and when I look at it for a couple hours, and don't solve my problem, I don't feel like I did anything, and feel as though it was a waste of time.

How do I spend more time programming, get more stuff done, and feel more productive after every programming session?

closed as off-topic by gnat, Doc Brown, Bart van Ingen Schenau, Robert Harvey, Ixrec May 31 '16 at 3:55

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions seeking career or education advice are off topic here. They are only meaningful to the asker and do not generate lasting value for the broader community. Furthermore, in most cases, any answer is going to be a subjective opinion that may not take into account all the nuances of a (your) particular circumstance." – gnat, Doc Brown, Bart van Ingen Schenau, Robert Harvey, Ixrec
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 5
    Knowing your environment is by no means a waste of time. If you know your OS/platform/system/ecosystem/etc. you'll be better at programming. – Tibo May 30 '16 at 6:53
  • 2
    for my personal project i adopt ad "industrial" approach even if it's one person team project. That is: before start coding i spend as much time as i want to make the analysis and design part, i choose the technologies I'm going to use and I study them . When i feel ready i divide all the work in tasks and i gave each task a valued to-do time. If i'm on schedule I'm being productive. If my estimated time simply was too unrealistic i reschedule everything from zero and i try to follow the new schedule. This helps me not only to measure my productivity but also as a discipline improver. – JoulinRouge May 30 '16 at 7:18
  • unfortunately all this stuff is part of the job. – Ewan May 30 '16 at 13:10
14

Assimilating the job of a programmer to coding is reductive. Your goal is not to write code, but to solve a given problem—usually through code, but not only code.

Once you have a set of requirements, you have to do a set of tasks in order to fulfill them. It can consist of writing code, but also doing architecture, writing deployment scripts, setting up and configuring external dependencies (such as Twilio), setting up production environment (such as Amazon AWS), writing tests, documenting stuff, etc.

In big companies, specific tasks are delegated to dedicated people. In small companies, usually the same person has a lot of different responsibilities. But even in large companies, writing a given subset of tests and documentation, doing design and figuring out how to run code on a given environment belongs to programmers. This, by itself, takes usually much more time than writing code.

Think about the goal. The goal is to respond to a need of your customer in a fast and inexpensive manner. Can you do it without running a Java program in the background or without putting a JAR in a JAR? If yes, you're indeed wasting your customer's time and money. If you can't, then by figuring out those two tasks, you are actually doing your job.

If you spent a day figuring it out, you spent your day working and learning, which is a day well spent. It doesn't matter that you wrote zero lines of code—this is one of the reasons why LOC/day metric makes no sense when comparing the productivity of programmers.

But, wait, what if another colleague would have figured out the solution in a matter of minutes instead of spending the whole day on the issue?

This is why experience is important. Knowing a programming language is not enough. You have to know the ecosystem as well, would it be the operating system, the framework or the tools (don't forget the tools!)

An experienced programmer will solve problems faster because he knows both the language and the ecosystem.

A programmer who knows the programming language but recently moved to an operating system he never used before will be less effective.

A programmer who knows the environment but recently started using a new programming language will be less effective too.

Not the answer you're looking for? Browse other questions tagged or ask your own question.