My government just realized that making anyone a developer means that these people becomes obsolete fast if you don't force them to re-educate 24/7/365.24/70. And my government is also asking themselves why on earth are the depressions, burn-outs and suicides on a sharp rise? You basically do 2 jobs at the same time just to preserve your current job.

Hard reality: Your half-life of a developer is 1.5 years.

Three Years from now, everything you learned so hard will be obsolete and you become useless.

Starting with Java 9 most Java version will only have a lifetime of 6 month. After this period no more updates will be provided for the version.

Then why should one use java if it becomes obsolete in 6 months? If you have only one application to keep up and running then it is ok but if you have an enterprise of tens or hundreds of components then you development costs will spiral out of control.

Also developers will say fuck you when you just release yet another java while they just learned the latest release.

My solution, get rid of this SCRUM and fire all those developers that had a SCRUM certification. Your productivity becomes 10 fold.

Nice to hear.

If you start with static classes first then you will end up having code that is not extendable and thread safe. Also you can always nail down a dynamic class as static like a singleton.

I tend to initialize static classes at my Main() first. This way I have a predictable place where the code gets initialized.

IoC tends to turn out into very messy code and hard to reverse engineer. If you did not create the code yourself or were part of it then you are toast.

In a perfect world where programs are perfect, analysis done right and developers never make mistakes, then IoC is good. But the hard reality is that when you inherit code that you started but others took over and they tell you fix the bugs.

On top of that IoC, actually explodes the amount of code that you need exponentially to do the exact same job.

The sad reality is that if jump on this IoC bandwagon, your brain gets trapped that this is the only possible solution and you lose the ability into train your brain into creativity. You become slave of the code, instead of the master.

My idea is an open discussion. Irrelevant if I agree or not, the whole point is that others gets inspiration from your contribution.

Your contribution no matter how lengthy it is, may become very interesting for future Voat readers that gets inspiration from your posts. I actually would love that you start your own discussions here on Voat too.

I really hope that v/programming becomes a very lively discussion part in the future. With passion fire and ice. Good versus Evil... :-)

And thinking through things can help very much - if for instance building a very large "monolith" for a given project will be very risky, time-consuming, difficult to maintain and might need a lot of (lucky and successful) design, requirements work, etc., it will typically be much, much better when possible to instead create a lot of smaller, independent applications, especially if these applications do not need to communicate with each other.

I always hear this "monolith" is bad, however all your independent modules will in the end grow into a giant monolith as they grow and tend to more and more interact with each other.

Monolith design can be as flexible as your independent applications but way way way faster and stable. It all depends on the quality developer that acted as a guide how to do it. This knowledge has been lost since SCRUM teams have become the norm. I have seen how very skilled developer have reverted into a losers mentality where failing a sprint has become a norm. Following the processes is now more important than creating good programs.

Monolithic programs are too slow to adapt? Have you not noticed that users are fed up with programs that change daily in functionality yet again? Changes are so fast that no one cares anymore. All they notice are icon changes, font changes, more animation but have no clue what changed in functionality. The users brain has adapted to these changes by ignoring what changed. No one cares anymore what is new.

The danger over time I have noticed is that you lose track what that LINQ statement actually does. A bug in the code somewhere else could trigger unexpected side effects you never could have predicted. You are at the mercy of the implementation behind LINQ to do the correct thing.

The other thing I have noticed when you are searching for bugs, your brain will actually ignore that LINQ part because it is too complicated to reverse engineer. It takes a lot of mental energy to understand the code. And during stress and deadlines, your brains skips over the obvious bug in that LINQ statement.

Also over time you will get scared to modify that LINQ statement so you create parallel code that almost does the same thing but not quite the same. Code gets duplicated, adding confusion because now you have more code in your project that looks similar. Before knowing you are modifying the wrong LINQ statement.

WOW, this is what I call code that rocks!

I look at it and I can instantly recognize the code. Your eyes gets drawn what is the real functional code and you ignore the noise that is not important.

Even without reading the code you can, based on the white space and the ordering of the words, sense that something is wrong in this code or not. This is important because just by scrolling at a relative fast pace I can now detect things that may give clues that it does not compute.

I started a "discussion" It is up to the people here to have their say. Improve me, educate others..... Explain to new developers that come here and show them how to do it correctly.

Discuss, share your knowledge start discussions yourself. Make sure that the next generation of developers are actually good!

And how is making code that is user friendly bad practice?

Bad developers sees the Software and CPU as just tools, the user is stupid. You get in a none-stop fight with your users that refuses to do it correctly.

Good developers uses these tools to elevate the code so that the users actually wants to use it. No actual interaction with your users is needed because it works intuitively.

Who do you think is the most productive developer? The one that keeps on fixing users issues or the one that gets uninterrupted development time to create even better code?

This was just a quick example.

For people on the support desk, logs should be as focused as possible to help aid a quick response.

10:30:40  - Retrieving list of customers for company 'WYZ'
10.30:41  - 100 customers retrieved.
10:30:42  - Verifying the list if we have corrupt date
10:30;42  - 2 instances of corrupt data found and removed
10:30:42 - emailing  98 customers for company 'WYZ'
10:30:45 - 95 customers successfully emailed, 3 failed.
10;30:45 -     - Customer 'abbbcc@hotmal.com' failed to deliver (Will be retried later)
10;30:45 -            -  (User is over the quota. You can try again later.) 
10;30:45 -     - Customer 'abbbcc122@Live.com' failed to deliver (Will be retried later)
10;30:45 -            -  (552 Message size exceeds fixed maximum message size (5000000) )
10;30:45 -     - Customer 'abbbcc122@doesnotexist.com' failed to deliver (Will not be retried)
10;30:45 -            -  (550 Invalid recipient )
10:30:45 - Updating database for 98 customers that succeeded and 3 failed .
10:30:45 -    -  Customer 'abbbcc122@doesnotexist.com' will be marked as to be verified by customer care.

Stop complaining and discuss why it is shitty.

The last one makes more sense, but still it forces you to think to find small issues. You create a wall of text with words that basically look the same '${pad(date.getUTC'

I mean it is hiding the true code which is "YYYY-MM-DD HH:mm:SS"

I am not that experienced in javascript, so this is out of my head.

const pad = n => n < 10 ? `0${n}` : n;
const DateOnly  = 
     datetime => `${datetime.getUTCFullYear()}-${pad(datetime.getUTCMonth() + 1)}-${pad(datetime.getUTCDate()}
const TimeOnly  = 
    datetime => ${pad(datetime.getUTCHours())}:${pad(datetime.getUTCMinutes())}:${datetime(date.getUTCSeconds())
const formatDateTime =
     datetime => `${DateOnly(datetime) TimeOnly(datetime)}

Logs should be the last resource to find the cause. Your job as a developer is to create good code. You should test every possibility before you deploy it.

The interesting thing is when you develop your code in such a way that it makes logs very readable, it actually helps you developing better products and way easier to test. On top of that your development will speed up making you even a better developer.

Under deadlines, stress this wall of text in the one-line could contain a bug and it will take hours to find the bug that you could have used for productivity.

const pad = n => n < 10 ? `0${n}` : n;
const formatDate = date => `${date.getUTCFullYear()}-${pad(date.getUTCMonth() + 1)}-${pad(date.getUTCDate())} ${pad(date.getUTCHours())}:${pad(date.getUTCMinutes())}:${pad(date.getUTCMilliSeconds())}`

Now spot the bug in this above example.

Now that I am long in the tooth I write programs that steer my users so they can't get into trouble in the first place.

Exactly!

Users are not the enemy. Frameworks and trendy fads are the enemy.

Frameworks never solves problems they causes problems in the long run.

I do get paid to program but I don't get paid to deal with users too stupid to read whatever error message I give them.

Unlike you, I actually make my program work and not cause errors.

In programming there is a survival of the fittest. If you don't follow the pace the others do, then you will never manage to catch up anymore. Your fun will be short-lived.

The fun is being better than the competition, break the laws of programming by doing stuff everybody else claims that it cannot be done. You are not a slave of the frameworks, you command the frameworks, even extend them if they fail to do what you want it to do.

That web site sucks on a desktop. It is the type of web site I click on and have this allergic reaction to to ever ever come back to that site ever again. I thought they finally got extinct!

These kind of web sites suck because they takes too much effort for the user to scroll through; After 2 scroll wheel clicks you get so bored that you go and see another site. You get bored because you start to realize that this site is so poor in content that they have to hide it behind scrolling stuff.

Great sites have great content. Content that is instantly visible and requires no user effort to scroll or swipe. Content that is instant clear where the links are and where you can press on without you to require to move the mouse or to find it.

IT engineers are definitely not programmers they basically stay on the scripting side while programmers tend to go deeper into compiled languages.

But I have to say that modern programmers, those have more and more deteriorated into script kiddies. They can't invent new technology when they need to, they rely on frameworks created by others. They have become very good at "name that framework" but very bad in what real programmers do: "Cheat" to by pass restrictions.

It is shocking to see that very good programmers have deteriorated into average by this SCRUM madness. The winners mentality has changed into the losers mentality where no one cares anymore if the sprint succeeds or not.

I work with Visual studio for more than a decade and it really is the best too to develop in. With the best tool I mean, I am very productive in outputting professional results in a very short time.

But with Visual Studio 2017 I see a disturbing trend that they output updates after updates after updates after updates to a point where no one in the developers team has the same Visual Studio 2017 anymore. The end result will be projects that starts to become more and more deteriorated and end up into failure after failure.

Looking back at LinkedIn, Skype and Windows 10, they will definately fuck it up. If you did not have migrated your project yet then your project will be dead soon.

Only when you have enough money to fight a lawsuit.

The safest way is to add random changes to it with several commits to make the code worthless and then deletes everything except for the readme.md pointing to the new location.

Valid points.

But now that Git has been integrated in every single Microsoft product, they may slightly modify the git so it becomes less and less distributed and more cloud central. If you make the Microsoft variant of git more useful and break the compatibility of the real Git protocol you can force developers into a strong hold.

Survival of the fittest. The one that controls the AI minions controls the world. It also a a great way to go stealth.

And the amount of people in your community that needs to find the new location.

You can fight back. Poison the well, generate projects that are worthless so confuse the AI they will use to traverse every single byte of your source code. It actually would be an interesting experiment to see how we can change the AI so it turns on against their own masters.

It is a source cloud code repository that was used for millions of Open Source projects. You could regard it as a central server where you share your work when you work on projects together.

https://en.wikipedia.org/wiki/GitHub

If you are a startup, you should move! Microsoft is probably going to let some AI lose on every single line of code and patent it before you can.

Move your Github repository first! The make Microsoft prove that they are worthy to put back your repository.

C# has a default constructor that takes no parameters. You dno't need to specify it. In this case all fields will automatically set to false, null or 0

It gets even worse, property girl inside class Guy is private so he will never get to meet any girl ever. This guy is DOOMED!

Yes and her age will be 0 (default = 0), so she will never date him ever.

It is interesting that the comment says that he should not be able to know her age but we do know it, it can only be 0 (default constructor).

Also the guy never gets a date since the girl is always age=0 and she will not date him noo mater if he is good or bad looking.

Something is wrong here, the girl is will only go out with a guy if SHE is 22+ and the guy is not ugly?

Search and replace girl to boy and see if it still compiles.

The biggest issue I have seen now is:

• Programmer A starts with feature A
• Programmer B starts with feature B

• Programmer C starts with feature C

• Tester tests Feature A and is OK

• Tester tests Feature B and is OK

• Tester tests Feature C and is OK

• Feature A gets merged to develop

• Feature B gets merged to develop

• Feature C gets merged to develop

• Develop is now broken nothing works but hey that is not for this SCRUM team we deploy it anyway.

Pushing alphas to production nowadays, we don't even bother to test.

"How many looked at the randomized controlled studies that provided evidence that agile was better than your current process?" she asked.

No response.

I have seen a guy using a external web rendering engine used as a component while all he had to do was a search and replace of a tag string in a static html file.

Now I am involved with a Javascrip project WTF!

Interesting, just noticed how old this game is, 1991, back in the days where good OOP developers were created.

Then why is no developer be able to program in an OOP way? The only people that can program in OOP are those programmers that started in 1995. Modern day developers use OOP as some glorified one dimensional namespace.

People that win the Darwin awards are not my friends.

Latest software technology.

I keep on inheriting these projects that tried all these packages and failed miserably over time when these packages grows out of tune.

Projects that can be perfectly done by one single person, now requires a complete SCRUM team, a PO and SCRUM master plus many dependencies of code by other SCRUM teams, specialized deployment tools, specialized unit tests and worst of all these projects SUCK in performance and the ability to easily adapt them!

The other issue is they keep on changing these packages every single day. You blink and they just released yet another new version that breaks older code. 90% of out time is wasted on keeping up with the rat race while we could have used this in productivity.

There is one good thing in all of this, it forces my mind to keep on evolving and find solutions where others fail. All these new technologies are destined to make projects fail, and then there is where I get hired, to save these projects.

This .NET core is heading for a disaster. It wants to go the Linux way with nuget packages, but my experience with all of this is that packages can break things. When I develop for .CORE I have lost control over my code and am at the mercy of others creating packages.

I never have a code version that can be predictable stable.

EDIT: this article, released on April Fool date, was an April Fool joke. So pointers are not going away.

What my plan is? I go anywhere where I am needed to fix the mess. If you don't want to renew my contract, I have no issues with that enough other places I can go to fix things.

Why have I been staying with your company for so long? Because I love the work, I love the development team, and I don't like to go away from software that is not fully delivered. If I give the software, then I guarantee you that it will be easy maintainable, surprisingly simple, can survive bad deployments, works rock solid and near zero bugs.

Of course, it is called "statistics".

Most developers have a very distinct programming style. Mine tends to be:

• Functions that do not exceed 4 parameters (because the 5th parameter cannot be saved into a register value, so you lose performance when you need to save that 5th parameter onto RAM.
• Methods that are short, since I write code that normally fits into one screen without need of scrolling.
• Methods where code can be used into multi threading with almost no requirements in locking.
• Speed per formant where the compiled code will always reach the end of the method without a jump condition for the most used functionality. This avoids unnecessary jumps in the assembler output and so the CPU does not have a cache miss and needs to reload the instructions from RAM.
• My code tends to fail gracefully, and I avoid throwing any exceptions.
• My code barely relies on libraries.
• Deletes in an list I always have a reverse loop to prevent accidental deleting of the next item.
• None repetitive assembly code since I do not copy and paste code.
• Reuse of code that I already developed on other projects.

Other clues will be in the usage of "strings" data.

AI tool, you don't need AI for this.

Mistake

Shame on your team. Code reviews are essential, even for highly qualified teams.

And yet we have the lowest bug count from the other teams.

I am thinking you can use a (Sorted)Dictionary, to convert the string fast to a single value (int). Then stage 2 is use that (int) value/Enum in the switch to call your methods.

If speed is not an issue then your solution may be equally good.

The problem with GetMethod() is that if some other developer changes the method name, then you end up with a bug. The compiler won't warn you. And the other developer may not realize that your code that contains Getmethod() is a switch.

If this is "_a = _a / 1.0" then "_a" may not have the same value anymore and introduce a very small epsilon error.

If _a=10, then may become _a == 10.0000000001 or _a == 9.99999999987

My experience with programming is that you can't predict what is the most efficient code. You need to try different ways and see which one works best for your problem.

So I propose to create a small program (Any language you desire ) to read in this source file and parses the function into a new C# source code that you then can test.

For speed, since the switch is a string, I would use some Dictionary collection so you can find fast look up the correct method/delegate/anonymous function for that command.

I use delegates the most: http://www.tutorialsteacher.com/csharp/csharp-delegates

So, yes, eventually, a good programmer will learn everything that needs to do his/her work, but collaborating with other peers will accelerate the learning pace.

Actually no. It slows them down. And as I have noticed you tend to copy the bad coding from others instead of better coding. The complete group is under the illusion that they work more efficient, but in reality they slowed to the worst developer in the team.

I think that this post is a rant because you think that you're far better than your coworkers... maybe it's even true, but that's not a very good reason to think that good programmers should learn in a lonely way.

It is the hype that pair programming or programming in a team will make the team 1+1>2 better. But in real world situations this is impossible, unless you are at equal footage. But that equal footage can't stay for long, one will speed up the other one will be left behind.

Also by doing pair programming, for you as a developer at this ends up badly as your career progresses. You never are forced into stretching your mind to solve an issue and no one is going to save you. You never learn to find solutions when everything is in fire. You never become better than the competition. You never become the alpha developer. You will end up as a beta developer that can be easily replaced by your company.

Currently I am in an incredible successful team. We work together but we don't do pair programming. We trust each other to complete his job, and they trust me to do my job. We all specialize in one part of the projects, there are no code reviews. However when it is needed, we can jump into the others code and fix the problems. Because we don't do pair programming, we don't waste time in communication overhead.

It is only temporary, in 3-5 years from now all these "diverse" companies have gone bust and those that survives are the ones you want to be in.

Also, SJW's don't tend to stay long, since they have to work too hard and people will notice. So they change company before people are noticing it.

We’re never going to get back to the 1980’s, but I don’t feel particularly sad. Even though the programming languages might — at least at first glances — be a bit more complicated, we’re living in a golden age of self-starters.

I disagree, with IoT everywhere, Arduino and ESP12 we are exactly back to the beginning.

I didn't even had a floppy drive back then.

There is none. It all depends on what you want to do and what the competition does. If the competition uses java or javascript then you must become better than the competition and use a language that will outperform them. It is completely useless to copy the competition because that way you never become better than them.