In my mind all these productivity systems cook down to creating a list of tasks. The list can be between 4 and 10 items. You do one task at a time and when you are finished you can cross out the task. This is the extent of focus my brain is capable of. Creating giant backlogs and plans is just | /dev/null in my case.
Because of inline css and different fonts on different os-es and generally no guarantees about render size. In short, you have no idea how big a block is without rendering it.
I remember the sysadmins trying to figure out why sqiud was so slow and tracing the system calls. It was because they did not use kqueue/epoll. When he asked the maintainer to improve on this he said squid was fast enough. This was the start of Varnish where one of main ideas was to use modern os-calls to speed up things.
I don't understand. You complain about coworkers getting high pay and complaining while not producing any value. Do you think a downturn and potentially getting fired will educate them in this matters and getting less pay will make them solve actual problems?
Yes, this is true as long as the method or function doesn't contain if's changing the behaviour depending on the data. In other words if the problem is so well defined that you can create a method that solves the problem and it doesn't need to take into account x variations of the problem then it is fine. This is the copy-paste versus creating a function discussion. Problem is the x variations of the problem and you need the code to do different things depending on the variation, we usually break the modularity of the function instead of separating the generic and non-generic parts. Hence the ifs in the function. From what I have seen people are unable to do this in their own codebase properly so I don't think it will happen globally. But on the other hand libraries are kind of the answer to the problem and as problems get well defined, one starts using libraries. Raising the level of abstraction is a continuous process.
At the end of the article: This is a clearly ambiguous merge and it simply wouldn’t be right for your version control system to try "resolving" it for you.
So the strategy is that if there is any doubt you have to manually fix conflicts. This is by design.
If you are used to being the guy everybody goes to it is a big change since nobody will depend on you if you are new. But that is fine, it takes som time to get recognised in a new work environment. If you are skilled it will change in 2-3 months.
The Online Etymology Dictionary states that the use of the term to mean "'calculating machine' (of any type) is from 1897.
The Online Etymology Dictionary indicates that the "modern use" of the term, to mean 'programmable digital electronic computer' dates from "1945 under this name
> Computers are programmable. A system created from logic gates, executing a fixed set of operations is not called a computer. Your washing machine is not a computer either.
>What has the world come to, where technology has been appropriated and we are left paying rents every month and companies are increasingly becoming user-hostile and predatory and monopolistic!
This is the issue. While the subscription model may be the right choice forward it may also be the catalyst of a collapse (like the dotcom bust) if the users get bullied enough.
Beware of the imposter syndrome. It never goes away. If your old code looks awful and embarrassing, you are on the right track (you are learning). Focus on learning to read code. It is more important than writing. Find a good open source project and read some good code.
I have ported a Spring Boot application from log4j to logback and it was pretty easy since we used slf4j. The code was the same, the only thing I had to do is to convert the logging configuration. The features mapped one to one and it to some fidgeting to make it work, but all in all it was pretty straight forward. Would recommend.
So when you sit in endless meaningless meetings and see how the management create insurmountable obstacles that make it impossible to actually do some meaningful work while whining about deadlines and changing the requirements on a whim, you should just be thankful that you have a nice paying job? Well you can be thankful and still cry inside since if the management were competent, you could get 3x done. If you feel this several decades you die inside little by little until you do what is described in the article.
Well, my experience is that to increase productivity the most important thing is not doing things. If you can filter out the meaningless features and shut down products that are a product of politics (giving someone a product to keep them happy even though everyone thinks it useless) you can increase productivity much more than focusing on the technical aspects of development.
Oh, wow. Usually I get asked to estimate with very vague descriptions of what I am going to build, with hard pressure on date of delivery. At one point I said to a manager that if he pushes hard enough he will get any estimate he wants. Well, for the scientifically inclined, humans can estimate programming tasks that take around one hour with good precision. Precision declines until one week and anything over a month is virtually impossible to estimate.
The Commander X16 is a computer that you should be able to understand how it works. You should be able to start the computer and poke away at the hardware and see results immediately. The Amiga is better and more usable, but it is a lot of complicated hardware.
One possibility is signed PDF's. You can verify that the corporation created the document, that it has not been changed. That is more security than a piece of paper. You can forge a document.
To be more specific, get rid of setters unless it is a data object. Have all fields be final and set them in one constructor. This makes the code more readable since you know no method will change the internal state.
I think that one part is the architecture. People use patterns to divide up code with duplication and interfaces. This makes the code more complex, but has some merit as the code is more testable and extendable. The second part is the use of object orientation to reduce code duplication. I am not a fan of this. It leads to deep stacks of inheritance where the code is smeared out in many layers. Modular code is much better in my opinion.
https://schoolyourself.org/learn/algebra is great. You start from addition subtraction and go through your list for the most part.
Khan academy is great too, but with schoolyourself you can walk through it a bit faster.
A programmer likes to learn new things all the time and sees the joy in writing the same code in a new language/framework for the n-th time.
A problem solver sees that it is pointless. You are just doing the same things over and over again and the shiny new thing is not that special.
You must rediscover the joy of learning new things. Try a new language or a hobby. Try some new food. Experience new things.
Programming requires true grit because the real work is not that exciting. Coding is just a small part. So you have to accept that to make great things you have to do a lot of boring work. And that great ideas are not worth that much without the ability to implement them.
In the old days if you managed to create a website it was great. Now people compare everything with Google and Facebook. If you just put something together fast people would just laugh at you. So everything takes a lot longer. The effect is that you get to solve less problems.
Yes, AlpaGo Zero is mainly self taught. It means it learned to play through the game mechanics. There are no databases of moves or smart optimizations that are based on our understanding of go.
Interesting, but it is not surprising that git and redis are more stable than node and angular. Git and redis are well defined problems that won't change that much. Angular is a framework and node is a platform. They should change more. But then again... javascript fatigue is a thing from what I heard.