They used to grind us down with pages of sums because they needed us to be calculating machines. Now they grind us down with bullshit because they need bullshitters. Now that AI really is a master of bullshit, they should leave us to be human beings.

It is the only way innovative code ever got written. The idea starts in your head and the structure that makes it work has to be coded up fast before it falls out of your head. At this stage I don't worry about public and private, const correctness or compiler warnings. I'm just interested in getting it all connected up so I have something to run and test. Then I go back and deal with const correctness etc. because that will help with writing the rest of the code. Nobody wants to admit that there isn't much between idea in head and working code.

Yes, the interview is also for you to see if you want to work there. Success is not having to work where you don't want to. Nevertheless keep your questions on discovering what the job is up to the point that you can credibly say if you are up to it or not. If you can't get to that point then you have encountered incoherence on their part or yours - it isn't going to work. You find out about toxic environments by listening and observing, not by asking questions that make you sound picky. Toxic bosses are very often fond of telling you so in the interview: 'I am a bit of a perfectionist' etc. Listen carefully to their spiel. You can smile politely as they say it but don't think that they don't mean it.

Just load the first 10 files. If the user goes for an 11th file then chuck the first 10 away and load the next 10 etc.. Optimised for less than 10 files but more can be reached. I imagine that it is intended to be minimally distracting to a performing musician so you don't want modal selection procedures. This way it remains a simple up/down selection but you get a bump delay as you cross 10, 20 etc. I would think that would be acceptable for such a device.

I learn by doing to and I have an enormous codebase of fantastical experimental ideas from which I have learned a lot but would not employ in production code. Having said that, I am retired now and can afford to be wise and circumspect. In fact I specialise in it because it is less stressful. Back in the day though, I used to innovate wildly and put it straight out in the field because it was needed. I had a lot of confidence in what I was doing but it did mean that I had to become an expert at completely refactoring my own innovations without breaking anything - usually because I hit a design cul-de-sac tying up loose ends. Yes, you do have to roll up your sleeves, get your hands dirty and have confidence in your own brilliant ideas. I still do it but I now have the luxury of only publishing what I want to when I think it is ready.

To be adventurous or to be prudent? Be adventurous about what you discover and prudent about what you implement. If you discover a better less error prone path then it could be prudent to implement it.

Absolutely. It is time to take half a day off. But first I have to deal with the urgent bodily needs that have been building up while I've been so concentrated on the task.

I've found that starting to write an article usually triggers a new phase of code refinement. When my explanation becomes too wordy and complex, I find myself returning to the code to remove complexity so I don't have to write so much about it. It results in better code and a more readable article. It sometimes requires changing design fundamentals and deep refactoring but I've got used to that now.

I found that Private sector Family Owned usually meant tolerating badly behaved management and a more personal feeling of being exploited.

But you don't want a good relationship if it is based on you being the looser.

People go to C# to escape scary old C++ and this is where they end up.

Whenever anyone tells you not to worry you should insist that they explain why you shouldn't worry. If they can't explain why then they are either hiding something from you or they are drunk on a culture of not worrying when really they should. Don't let them keep you in the dark because that will cause you a lot of worry. If disaster strikes then saying that they told you not to worry about it is going to sound a bit lame.

The problem is that Developer and Software Engineer titles can be given to 'high level' roles that don't go anywhere near writing or even reading code. I am retired now and would describe myself has having been a software author. Someone who designed and wrote software.

I'm old and retired but I love programming enough that I regularly spend 3 or 4 hours a day coding and understand what I am doing so much more than I ever did before. I'm not available for hire though because no way will I work more than those 3 or 4 hours.

There is nothing wrong with using a simple algorithm that you understand and that is adequate to the task. It sometimes easier to write a simple bubble sort than to do the work of interfacing with a library function.

If you are outsourceing any more than very simple routine stuff then you are not what you say you are then you are not writing the software, your outsourcer is. God help you.

Not a lot really. I stick to solving almost everything with C++ and try hard to avoid having to immerse myself too much in anything else that isn't the job in hand. I have seen many things come and go and I am very relaxed about not having bothered to learn them. Why think that you have to be master of everything? That is megalomania. You might think it looks good on your CV but to me, any profficiency list with more than three items looks like a list of superficial dabblings.

Bjorn, if you only work 4 hours a day then you can't be very exited about the work you are doing. This is another issue. If in pursuit of avoiding burnout you deny your own creative urges then that will also hurt. When in create and construct mode I often work long hours for several days because you have to put a lot together before you can test your design and you want to do this quickly. This is not burnout, it is a much needed release of creative energy that leaves me feeling well. I have not driven myself hard I have just not been able to resist taking the next step on the adventure. It is like reading a good book. Any fixed timetable will prevent me from having those creative binges and also deny me the opportunity to recover from them. I know full well that I can't work like this all the time. You can't spend all your life reading good books either. It sounds like you have made a correct and decisive decision to avoid burnout. That is good especially if you have a family. I am only suggesting that you have work days and relax days rather than doing a regular bit each day. I find that the only rhythm that works for me is the rhythm that happens. I enjoy several days of working and I enjoy several days of not working.

Hi Bjorn, thanks for your reply. I think that what all enthusiastic programmers must realise is that you have to plan your own rehabilitation and do it your own way. It is very difficult to do this as an employee because superhuman efforts are not recognised (are even resented) and daily drudge is required relentlessly. The only time I have felt decently paid and decently treated is on short term contracts of 3 to 4 months with a specific goal for which I have taken personal responsibility. The saying of contractors is “Take the money and run” but it is more like “Perform the miracle and run” and that suits me. Workplace environments are typically so dysfunctional that any success simply breeds suspicion and resentment. I have found that the certainty that my stay is not permanent leaves everyone concerned a lot more comfortable. I have just finished 8 years of permanent employment in Spain. Despite some very successful projects it finished badly. I think they were becoming uncomfortable about the inevitability of having to give me credit for what I had done. Now it is time for my rehabilitation and I am looking forward to it. I do think that regular office bound employment is no place for a good creative programmer.

We routinely solve problems that others don't even know exist. We have performed a miracle but we are perceived as having simply carried out a task. This leads to lack of appreciation that we try to rectify by performing yet more miracles. We become quite good and seek to prove this by taking on something truly large and complex. We drive ourselves into it on the basis that we can see that it can be done and how. We then work relentlessly to realise our vision and we are in trouble. We are now constantly compensating for complexity that we didn't anticipate by trying to get the extra work done unseen. We shoulder this extra burden because we want to see our vision realised and prove that it will work. While you are immersed in this it quite likely that some of your colleagues may be moving against you. They may resent your intention to produce a spectacular miracle that could overshadow their work or the freedom you may have been given to burn yourself out at home and you haven't been devoting much time to office politics recently. Our enthusiasm combined with a wish to please and be appreciated get us into trouble. You have to let enthusiasm flow when it is there but we should be very measured about our wish to please and be appreciated. Ideally I like an intense project of about 4 months and then 8 months rest. That way, each project is fresh and new. It is important to understand that skills don't rust. You can take a long break and they will still be there but you may find that you now make more mature use of them.