When I get projects in my hand from someone else, they always think that the person that originally created it is good. Reality is that I fixes all his bug and don't even bother to report it.

You don't get rich when you do good work because people assume that it is something easy you do. .

I know Pascal, C, C++ (Borland/Microsoft), C; F#, Delphi, Javascript, Python, 8080, 8086..Pentium, 68000...68020 , MMX, SSD, CUDA,... I probably forgot a few I think.

This is cheating. Now how much does an average bug hunter make compared to an average software engineer?

Wrong mindset, your job will become obsolete in 5 years from now. If you focus your brain in only one language then you will never have the brainpower to switch languages as your language becomes obsolete.

What are the best programing languages to learn that I could use to build different side projects?

ALL of them, or at least as many as you have time for. You don't need to be perfect in it, just understand 90% of it.

Everybody is aware of it, everybody in my team are about to jump ship this year. And many other people already jumped ship in other teams. They are losing a lot of very experienced people the last few months.

That is because I am using all my free time to learn everything possible because I am jumping ship at my client. Fed up with this zero productivity with this AGILE madness.

Great software is not created by a team but in most of the cases one developer that fixes all the issues the other team members have caused.

I understand the logic, this way you separate dangerous code from messing with your OS. If they developed it in C++ then there is a chance that it compromises the flight systems.

This only works with good developers. Those developers most enterprises will refuse to hire because they fail the bingo word tests.

Now how do you know that you have a good developer? Easy give him failed projects and see if he can bring order into the chaos without rewriting from scratch!! and make projects function even if they are still buggy as hell.

The second clue that you have a good developer is when the code that was in pure chaos becomes readable and easy to alter. Good developer can reverse engineer the code by only seeing the code and modify it in such a way that it behaves exactly the same as before but more readable.

So the Kanban approach is basically splitting up all of the work into the small tasks (i. e. issue, bug, feature), organizing them into different cards, prioritizing them accordingly, and moving them through the one workflow like, “to do -> in progress -> done.”

This sucks in real development. It only functions as a theoretical model but the failure here is that software is built onto layers and layers of buggy code, making your basis unpredictable.

• The failure here is not to recognize that not everything can be quantized and locked into "tasks". Not all developers are equal!
• The failure here is not to recognize that you will have idiots in your team that will damage your hard work.
• The failure here is that your team won't understand what you are doing and will fight you. They will stick to their methodology no matter what damaging the complete project even further.
• The failure here is not to recognize that after the sprint what you get is what you deploy even if it is buggy as hell because time's up!
• The failure here is not to recognize that some parts of the code must be slowly modified over very long times that does not fit into a task. You modify them when you have time and when you have rasher sharp focus. You don't modify it because your SCRUM planing says you must.

Bing back productivity! Bring back good code! Bring back creativity! Let the madness called AGILE be thrown in the abyss.

When you hear the word "Software methodology" then you are guaranteed to end up with crap. Very expensive crap.

The word '"Software methodology" is actually used by people that have no understanding what software development means and by teachers that wants to sell yet another useless very expensive courses to people that are below average.

No one believes me but I am going to repeat it again. one "good" developer will can perform the same productive outcome as a complete SCRUM team. One good developer will work very optimized, no slow down by other idiot developers, useless meetings, useless debates and discussion and still create code that will be future proof and agile. He will create future proof because he realizes very well that he is going to eat his own shit and that bug he ignored will smack him back in his face. He will create better code because no one else will save his ass when the deployment fails.

Good solutions are always written optimized for what the company needs. A generic solution will always produce bad results.

It is strange how programmers wants to have an boolean separation: either Waterfall OR AGILE, either Functional OR none-functional, either Top-Down OR Bottom-up....

The hard reality in software design is that neither works. The best software is written based on what is needed for that part and team. When you look at my code it has parts AGIL it has parts Waterfall. It has parts bottom-up and parts top-down.

The Tao moves in mysterious ways.

The master programmer moves from program to program without fear. No change in management can harm him. He will not be fired, even if the project is cancelled. Why is this? He is filled with Tao.

Thus spake the master programmer:

After three days without programming, life becomes meaningless.

So true!

They didn't use pair programming.

I don't know it all, it takes only a little bit of more effort to dig into the part I asked. The only reason why I asked them is give them a chance to contribute too.

I also do that. I look how the others do it and what works I integrate into my own work-flow.

Your experience is clearly that of someone who works on teams with a wild gradient in abilities, but a well recruited team would be far more balanced.

No that is the myth. You can only create a balanced team by throwing out the good ones and all you get are the averaged developers. The problem with average team is that no one has the horsepower to break through barriers that you will encounter.

It gives you the false illusion that your team is doing great but in reality is vastly under performs. But if you have nothing to compare to so you don't know that your team is not that great.

And yes! Less developers in your team means less meetings, less communication, overhead, less redundant code, more optimized code, better quality of code, less testing, less bugs = More successful projects and higher throughput. But the key is to have a good developer.

he wont learn dick just by watching. He needs to type it himself, fuck it up, fix it, rinse and repeat.

You got it! Good code is not by copying what others have done before but create a mindset to solve things.

My point is that inexperienced developers gets frustrated because they can't keep up. My other point is that good developers, even inexperienced ones, have a natural tendency to automatically figure it out, they don't need my mentoring.

You don't become a good developer with a mentor, just a code monkey that will be replaced within 5 years by another code monkey.

That is why it is good that you link them here.

Current education don't create software masters but code monkeys. Masters will violate every single design patter if it prevents them to fulfill the destination.

I really wish that these API designers would read and fully understand such papers.

So many enterprise software that I get handed over that are just one dimensional thinking. All these API's are basically simplified SQL query's but then mapped into some web service. Most of them make no sense to even exist because they almost have a one to one relationship to the database.

We are in 2018 and I stills see enterprise code that looked to be developed in the 1990's VB area. One would expect to have more mature developers by now that can write something more structurally than simple Console.WriteLn("Hello World"); functions.

Why as a developer do you want to be anonymous?

Microsoft is making a big pile of HS with all these different variations of .NET frameworks. They are spreading their development thin because they have to cover all these variations of the .NET framework. This means that they will become more and more infected by bugs.

Something new you want to explore in AI:

Capsule Networks: An Improvement to Convolutional Networks: https://www.youtube.com/watch?v=VKoLGnq15RM

You have * CNN: Image recognition * RNN: Sound recofnition.

RNN and CNN are just neural netts orderer in a different configuration.

The issue with CNN is that when you tilt year head then that spy-camera has a harder time to recognize you. Capsule networks are a solution but it may only work at small scales.

AI is becoming important. Not because it will take over the world, and humanity, but some aspects are very interesting to include in your conventional programming.

AI consumes too much energy for simple operation.

I have seen a lot of developers getting confused when to use a method and when to use a property. Although I avoid using exceptions because they cause more problems than it solves, I do know that sometimes an exception should be thrown.

The thing is that more and more properties gets loaded with code that should be included in a method only, it is tempting to start triggering an exception if the value that you load is out of bounds.

So the discussion could be if it is OK to have exceptions inside a property method or not?

Another question you may ask is if it is a good idea to throw an exception in a property?

I see it over and over again... They always think that the other side will solve all problems. And every single time they end up having the exact same failure, just slightly different problems. There is no one single solution that fits all. It always comes down to that one developer in your team that has enough creativity to bring your project home.

I like this Webassembly, because it means that the learning curve is very steep and it increases my demand. It is a path script kiddies can't reach :-)

Sticking to a oversized gaming PC with a fixed keyboard and a fixed screen. Better ergonomics and better for the eyes.

Another pattern that is starting to emerge is centralisation- decentralisation- centralisation- decantralisation...

Applications on Mainframes, Applications on local hard disk PCs, Application one the Novell server, Applications on the local hard disk, Applications on the web server, Applications on the local hard disk, Applications in the cloud, Web assembly on your local hard disk....

We are also heading back to DOS console commands. Every modern web site has changed onto some glorified console application. If you need something then you have to type in the commands. Gone are the days of the button presses.

For me, I develop mainly in C# is Resharper. I hate their subscription model, I would instantly drop it if I could but there is simple no replacement for that quality.

The reason why I like Resharper is because it speeds me up developing. I can focus on what I want to develop and not waste time on the syntax. One of the coolest things of resharper is that with a flick of a switch I can convert an if-else-if-else into a switch. Invert an if-else, change linq to foreach to linq... Stuff that I can do but now I can create sloppy code, then flip the switch and it converts the code. If I don't like the result than I press CTRL-Z and continue with the original code.

The end result is always rock solid code, that will be very easy to read and near bug free!

Hilarious, we are back at square one when they start to install complete executable assemblies on your PC to run their software. Fat client, thin client, fat client thin client. Seen this many times happen over the decades. Nothing new is invented, just running in circles over and over again.

TensorFlow Machine Learning Cookbook is for me the best one so far.

It doesn't delve too deep into the mathematics, it actually explains what you can do with it. The hardest part is actually getting it installed and functional. In that they still need some coding to do to make it user friendly.

I think you may like TensorFlow. It is basically the ASP.NET framework to create HTML but this library spits out neural network execution "graphs" that then gets executed as vector math.

The cool thing about these TensorFlow graphs is that you construct them as you want. Similar like panels in HTML pages. You are still a programmer that crates these functions. And you decide how to combine these functions.

In programming the majority are actually very bad. They are good a one line SQL queries, they are good at using enterprise libraries and design patterns. They are good at scripting code. But their mindset is stuck to only what others have told them and they have no clue that there are other and way more better ways to do it.

I recently discovered that it is especially the younger generation that gets so easily manipulated in creating modern crappy code nowadays. I am seeing how very talented developers suddenly start to create worse crap that they were fixing in the first place.

It is upsetting because the last few weeks I am repairing their stuff that they started but sudden lost interest in. Now they started with other stuff that is even worse. It is amazing how a team of talented people gets sucked into this modern style of applications that are ergonomic the worst. The sad part of all this is that this will become a wasted generation. In 10 years from now they either burn up or get into a depression. While I will keep on developing.

This actually looks interesting.

Even if you don't use it, the interesting thing is the way how they define the language. I also like the fact that they call it Q#.

I never heard about Rust

The truth must be said, even if I risk getting upvotes!

Everyone should at least have written a small C program.

C/C++ is not that hard but you are forced to be more responsible with your code. It brings your mind out of the comfort zone and find new ways to make your favorite language even better.

These are SPAM generators.

Also if you are a developer, you should stay away from that. Only script kiddies would use such a thing and create applications that is no better than the competition. If you are no better that the other 10.000 competition apps then your product already failed.

When an exception is thrown in your code, it basically means: You suck at coding!

Real developers will have an error reporting mechanism that gives meaningful information in a user friendly way that does not require a stack trace to go through nor log files.

NEVER!

A constructor should always be sometime that is fast and cannot goes wrong. It is one of the thew methods that should be 100% bug free and not lose time.

The whole reason why you need a constructor is to set up a predictable environment that is fully functional and not partially initialized.

Also avoid exceptions at all costs. It should only happen when something is very wrong, and not part of your normal operation. It should only happen once every million years of your code running. Exceptions cause a giant stack trace with worthless information no one understands.

Be careful, I could be 50 even 60. The knowledge curve in the computer field is almost flat before the 1980's.

No I started with Z80 Assembler in the 80's before the ZX80 came out.

I like GIT because it makes me develop code way faster than I used to. However, only when I work alone.

The collaboration part of GIT actually makes developers below average. Software projects tends to become below average. And the reason is that you as a team are actually slowing down the best developer. You slow down the best developer because you just outnumber him.

You do realize that you are posting articles most developers here even have no clue what it remotely is about? Which is good because we need to up the quality of developers.

Funny, I started with F#. I always liked it but then I realized that if I wrote F# at my company no one else would be able to fix bugs in it. So I stayed in C#.

People are not aware anymore that they suck at programming. When everyone else sucks too then you simply don't know.

Even if you develop in C# or Java you should look at the assembler generated. Then adapt your programming style to make the most optimal assembler output. I had many fights with colleagues that claimed that that specific Intel compiler created superior assembler output. I kept on telling them that the compiler does not matter, when you learn how C++ gets translated to assembler then you can also discover how you can write your code so the assembler is always optimal.

When you rely on the C++ compiler to create better results, then you get random results. But if you learn yourself how to alter the C+ code then you get 100% guaranteed fastest results.

One such example I have learned back then/ register calling convention only works for 4 arguments you pass on. The fifth will be stored on the stack and requires a PUSH and POP, which is slower. So I always limited the number of parameters to 4 (static method) 3 (object method)

This is why software projects always fails. It becomes so abstract that it loses reality and fails in the real world.

I keep on seeing these changes in C++, but so far most of the features are basically useless and makes C++ even more confusing to use.

An all I wanted is to have a clear error when I made a typing mistake. I still need a day of reading the compiler errors logged to discover that I somehow forgot a simple ';' somewhere out there.

This one big pile of BS.

Software does evolve and does not always act "logical" because of bugs and piles of library bugs, no where is it like you describe. It is this mindset that probably invented SCRUM and SCRUM sucks!

Also software is forced by complete idiots that invents idiot rules and then convince managers their idiots rules and promise big cos savings. Then these managers forces their people to these idiot courses and turn good developers into complete idiot developers to a point when no one realizes anymore how good software looks.

And it makes your code even more unreadable.

But agile fits corporate really nicely.

The art of working at 100% capacity and produce nothing productively.

What is this crap? Get rid of cloud computing, get rid of micro services, and get rid of this SCRUM and everything will magically fix itself.

I am impressed in the wisdom of you answer.

I think it is a SCAM by coding schools to have a continuous cycle of people that needs to get reeducated every year an get a new certificate every year. You don't teach developers to code in these schools, you get them brainwashed into thinking that this is the only way to write code.

Textbook examples but does not make you a good developer.

This is what makes a good developer:

• Never ever blame a bug in your code on something external. Learn from it and adapt your code so that fail never happens again. Giving excuses is the hallmark of a bad developer. 'but but, you did not install SP3.0.1.21.21 from you need to install SP3 SP3.0.1.21.22 instead.
• Any code you find on the Internet, take it and make it better. Fit it into your current design.
• Methodologies, design patterns sucks. Be aware that they exist, use them if you need but be very aware that they more probably will cause more problems that solve things.
• Design your code for failure upfront. It is more friendly for the tester and your code will naturally become controllable. You get better error messages, you get control of phone calls that prevents you to fix that bug.
• Realize that there is non single good solution. There are many ways and they will all suck. Most of the time you can solve the issue by pure brainpower instead of jumping to yet another library. It is not the first time that I see some person use a stupid big library just to read in a stupid simple html page to search and replace some element. A stupid text file read and write could have handled that job.
• Design the code in such a way so that testers can easily test it. If a tester can easily test it so can you. His bug report will easily pinpoint you to the exact location.
• Optimize upfront. The single method should not be optimized yet but the design of your application will do more than the fact is you use StrighBuilder or not.
• Mocking, Unit tests should be kept to a minimum. 90% of my code is fully production code. The mocking and unit tests introduces noise in your code causing more problems than what it is worth.
• AGILE, SCRUM unit tests are not your friend. It gives a false sense of security but in a lot of cases it is rotting your code base under that shiny green build status LED s.
• Survival of the fittest, the modern AGILE and SCRUM has crippled my productivity. However I have adapted my coding styles to make sure that I hit that user story mark every single time. Team work is nice but in the end your job is at the line if you keep on missing that user story.

And as last: For gods sake stop this stupid mantra that "SCRUM is supposed to fail". If you call yourself a developer you should kick that losers mentality out of the window and not allow failures in the first place.

I have noticed that there is shift in maximum age on software engineering. When I was just starting 35 was the maximum age companies would hire a developer. Nowadays it seems to be 50+ because a lot of managers also get older in those fields.

If you don't have a self-teach mindset then your coding career will be over in about 3 years. 3 years is the time when technology gets outdated.

He is spot on, micro services? We are running in circles and keep on using recycled technology that before proven not to work great, just slapped another new name on it and pretend that it is something new.

It baffels me that after these many decades, developers still can't program. Staring at flat-spaced design patterns, but unfit to create their own new design pattern for the problem that they want to solve. There is no such thing as one design fits all, not even in one single project.

Note the remarks of: Vendor Lockin

Our interviews are very real-world, and of course still many people don't make the grade.

I'm sure I wouldn't. I have software deployed in C, C++, C#, Go, Python, SQL92, JavaScript, TypeScript and Kotlin on 4 different embedded ARM architectures plus Linux, Windows and FreeRTOS.

Can I remember the exact syntax, APIs, class libraries etc for all of them off the top of my head? Of course not. As with law (my other subject), you pull all the relevant information from archive into active memory to deal with the case you're handling, then flush most of it again when you context switch to something else.

If you ask me a programming question "cold" you'll get an answer in procedural Pascal. I can't remember map/reduce syntax in every damn language off the top of my head and I'm not going to try. As with law (again), the key to productivity isn't remembering every precedent verbatim it is knowing: that a precedent exists, where to find the details and how to apply it to the problem at hand.

Please notice that post in the comment sections. He is spot on!

If you ask me a question about a topic, then I will answer "I don't know".

The day after I know the complete answer, the week later I become the expert.I become the expert because I had a couple of hours to search the information.

Be careful with Hooktube, it is a single point of failure. If it gets taken down then you lose all your links you collected.

What this world need is affordable software for disabled people. When you look at all the existing products then you can clearly see massive big money grabs from sick people that have no other alternatives.

I understand why people jump to these packages. In theory it should all work nicely. But the hard readily is that more and more developers have become script kiddies that have no clue anymore what they are designing; This in turn has made good developers into a small minority and being shut out from creating great products.

We are at a point where so many dependencies exist that your complete project can fail because some idiot modified one single line in the other dependencies. The end-result is a massive insecure number of packages that no one can control anymore.

We are now at a point where we have to develop code to keep your projects floating while in reality you can kick out 99% of that code and design it yourself. More developers does not mean better, just a massive overhead of internal communication and projects that end up in failure over time.

Ben there, done that, these blocks suck. All you do it create yet another average app that looks and feels exactly like the competition. And the worst part of all, using these premade blocks actually cripple your productivity. You are wasting 90% of your time on making these blocks do what you want that could have been used to make a better app that kicks competitions ass.

I come from an Assembler first background before I learned my second language Basic. Assembler is not that hard.

The problem with Micro-services is that you need 10 or more CPU power to do the same thing as more complex services. Not to mention time lags when they call each other.

The biggest issue with micro services is unrepeatable, unpredictable, uncontrollable big fat spaghetti structure that can come down in a cascading failure by a simple deploy that went wrong. In addition you will also have bugs that no one can find because no one can repeat them.

You can't master C in a week! It is impossible.

Unless you stay with simple "Hello World" programs.

Keep on dreaming!

I used to program C++ in that editor! Turbo C++.