Usually the developers like to use powerful computers.
They can explain this with many reasons, but the truth is that it is easy to work on a faster computer and the developers are usually rich enough to be able to buy a high-end machine. Or their employers are.
But, come on! Today, even the slowest low-end netbook has huge (I mean HUGE!) computational power.
If we, the experts, can't setup our processes to work great on this extremely fast hardware, how we can ask our users to use our software on their slow, old, cheap machines?
In addition, my experience clearly shows that the programmers improve their software only until it works acceptably fast on their own computer.
Beyond this point the programmer will cook up thousand excuses and explanations, but will not optimize further.
Will claim it is impossible, will talk about "premature optimizations" and will threaten about very expensive and hard support.
The truth is that the optimization is tedious process and when you can't feel the acceleration, you will never understand why you should make this work instead of programming something funny.
So, working on the slower machine, the programmer will always create software of higher quality. This effect works automatically and unconsciously.
That is why I am using for programming, the slowest possible computer I was able to buy (and that has more or less modern hardware, supporting the latest CPU extensions).
It is ASUS X102BA netbook with AMD A4-1200 CPU (2 cores, working on 1GHz), 4GB of RAM and 500GB HDD;
It is running Manjaro Linux with XFCE.
When I am in the office, I am connecting external HDMI display (2560x1440) and good mechanical keyboard.
In addition to the very high positive effect on the quality of my programs, the netbook has additional advantage - it is pretty mobile - very small (266x185x23 mm) and very lightweight (1.1 kg). I am carrying it always with me and can start to program instantly in every moment.
What you think about such point of view?
Latest comments (36)
When I bought my laptop last year, I did it for the same reason :) Acer Aspire 3 w/ Intel Pentium 4417U/4GB RAM/Intel HD Graphics 610 iGPU/500GB HDD. This was the most I wanted out of my development machine, since it's an 8th Gen Intel CPU with all modern features and still dual core and cheap. Btw I'm a student, and not an actual developer.
I do want to study machine learning however, but for that a budget gaming laptop which costs 4 times more won't be much different from this one (because I can almost do the same stuff in this machine with some more patience) I have so I'm saving for the best laptop available.
I would like to point out that, others would've mentioned it too - working on a high end machine is not all that bad. In fact it can make the process easier for you because the main work can be done faster. Then test it on a lower end device and optimize there. That should yield the best results. :)
No, unfortunately, this "trick" is not working at all. In such an arrangement, you will blame your test machine for being slow, not your code. "It is working well on my machine" is very common way of thinking.
I maintain some legacy software written in Delphi. Instead of having to reinstall it every five years or so, I keep it in a Hyper-V VM and just use that. It gets backed up (all 30 GB) when changed.
My current PC is 4 years old so only i7-5930K with 64 GB RAM but when it comes to VMs like this, more RAM is better.
Now I'm just highlighting an edge case you might not have considered. I also develop software that runs on a Raspberry PI so I am familiar with your pov. But developing for a low end PC is not the same as developing on it. I would be tying my arm behind my back if I developed on the PI.
I totally agree on the fact that
I saw that when I was doing Mobile applications. Whether it is on iOS or Android, developers tends to have the highest end mobile available and are developing on it. And when it is working properly on the latest OS version on the latest high end mobile, they tend to not optimizing it any further.
I would heavily recommend that developers have a low end mobile device and put into the Definition of Done (I assume that you work using Agile methodologies) that the software must work properly on the low end target device.
I totally on the fact that
I saw that when I was doing Mobile applications. Whether it is on iOS or Android, developers tends to have the highest end mobile available and are developing on it. And when it is working properly on the latest OS version on the latest high end mobile, they tend to not optimizing it any further.
I would heavily recommend that developers have a low end mobile device and put into the Definition of Done (I assume that you work using Agile methodologies) that the software must work properly on the low end target device.
Nikita Prokopov summed up this very beautifully in his blog post -- tonsky.me/blog/disenchantment/
Thanks! It is a great article I read before. But will reread it again with pleasure.
Totally depends on the kind of work you do. From anecdotally knowledge I'd second that having to work your way around the limitations of your hardware can make one create more clever and efficient solutions.
I'd never sacrifice productivity for this kind of hypothetical optimization though. The question is how valuable your own time is to you.
I'm in my mid 30s, having two kids and a bunch of other things to do. To me time not only equals money. It's quality of life. 10 years back and I might have been in for any kind of (micro-)optimization just for the sake of it.
In the end my objective is getting things done and maximizing fun and productivity while doing it.
I'm a Front End Dev, FWIW.
There is some merit in what you are saying, but it only makes sense to a point. For example, should you dev without any screen -- instead relying on a screen reader -- to make sure that you produce accessible apps? Assuming you do that, how are you going to know if the app looks as you intended when someone does have a monitor?
Or if you produce code on low-powered devices, how do you know if it will scale up in capability with higher powered devices? (Or that it will even work anymore?)
Rather than focusing on constraining your dev machine artificially, it's probably better to test the end product on the environments (along with their constraints) you are targeting.
You are right to the some extent. And I can think about many other examples and counterexamples. But it all depends on what you as a developer really want. If you want to make really accessible application, especially targeted for a blind people and want to make it in a best possible way, you definitely should have an visually impaired programmer in the team.
You may have great QA team that to test the program and claim it is slow, but if the developers think (subconsciously) that the program is fast enough, it will never be fixed. The development speed will slow down and the developers will find a way to persuade all around that it is impossible to make this program faster. The release date will come and the program will be released slow.
So, if you can suggest the developers that the program is slow in a way they really believe it (not simply to agree) they will make it faster. If not, well, the next slow program will be released.
Seems like there is a bigger problem with the organization if no one will listen. Low powered dev machines won't help that.
Oh, they will listen carefully. And they will agree. But only in words.
yes I would love to work in a slow machine, so as when I have to compile a humongous project I can mess around longer.
when I joined my current company they gave me an old slow laptop. Our main project took 35 min to compile. A few months ago, we switch to a new and powerful laptop, it takes 3 minutes....guess which one caused more frustration.
Not to mention no client will have to go through that process. I deploy my backend apps on aws micro machines so, yeah they need to be optimised and fast. I deploy my angular front end in S3 buckets, the client will never go through the pain of building the project, he doesn't necessary need a fast machine.
Interesting, but all developers complaining about slow compilation and lose of productivity on a slow computer. But somehow forget about the incremental builds. If your project is correctly structured, you have to build it only once. All future compilations are only on the modules you changed and modules that depend on the changed modules.
So, if you are working on a slow computer and really, really want to do the job, you always can setup your build environment properly and build fast.
Even if you are working on a module that all other modules use, you can create small test project that use this module and work with it, not building the whole project at all.
There is always solution, if you want to make it. And there is always an excuse, if you don't want to make it.
This is indeed true and it can work fine for a few hours. But in real world scenarios that doesn't easily hold. If you work on a specific branch all alone without being bothered, it works. When you have 15 people working on the same project and you need to rebase every couple of hours plus visual studio untrustworthiness that means you either need to keep track of other people changes and rebuild specific modules or rebuild the whole thing. Unit tests are again a good way around but the same problem applied ...rebuilding the test project takes time. I am not complaining but it's a issue I rather not worry about....than being ...oh my *** I need to rebuild again...and I just made coffee
I totally agree with you.
a few months ago I read an artical about the text editor and interviews acceptance relationship and it show most of people don't use vi/emacs, we know why, but the vi/emacs users has the higher acceptance rate -please if you did read the artical reply with the url cuz I can't found it-.
the explanation is simple, most of vi/emacs users write code to solve their own daily problem instead if just install plugins bu clicking.
Same thing about GNU/Linux or BSD vs mac or windows.
And it is. But it works for me.
Notice, that I am using only tools that performs fast enough to not slow my working process.
For example my typical builds on approximately 500Kloc of code is something like 3..4 seconds.
My IDE runs instantly and my keyboard repeat rate is set to 50 characters per second (and 250ms initial delay) in order to allow faster navigation in the source.
The same is about the version control system and any other tool I am using. The only not-so-good performing are the graphics editors Inkscape and Gimp are slow as hell. But well, I am looking for something better and will find it some day.