Most teams plan in hardening sprints to catch up on anything falling behind.

I have never seen this happening. Worked in different companies now, but there was never time to fix things. Just projects coming to a crawling halt and the team self destructs.

Neither waterfall or Agile works very well. Most optimal is a mixture of them. Long term and short term goals with fuzzy dead-lines optimized for the time and resource you have.

Because it triggers a curiosity that does not take the obvious answer for granted. It challenges your already clear solution and it uncovers bugs or new ideas that even works better.

80% of the work product is produced by 20% of the people.

That fits my observation. I have noticed that when Agile fails they add more people, but then it fails even harder. These managers now start to panic and try to control the project even harder, but kills off any good developer.

So many people that have them are completely useless.

I have seen it so many times that nowadays for me it is a clue that this person may not be that good.

The big problem of the certificates is that you become exactly the same as all other 100 people that have this exact same certificate. This certificate program kills developers creativity and you never become good, just average. And the reason why you become average is because you are forced to think inside the box, never outside the box.

And the bigger problem is that because your certification forces you to think inside the box, you will tempt to kill other developers work that do not follow your patterns killing any chance of success for your project to succeed.

I have not thought about it that was, but it is indeed a revenue stream.

I think this product sucks big. Not even a real programmer would dare to wear that.

Developers that are worth their money don't have to hide behind a certificate, they let their previous work testify instead.

I assume you are talking about mobile.

No desktop. I need to move the mouse and my hands bigger distances compared to applications from 2010. I used to have a shortcut now I have to press on one screen, then another screen and yet another screen to the content I am interested in. Also the content was visible in one screen now now you have to scroll.

It is creating an ergonomics disaster and a whole series of new technology related illnesses in the next decade to come. Modern applications have become so bad that I am sticking to any older software and not buy the latest version. Which is crazy because up till last year I always updated my software, now I don't want it. (Also because of the DRM that breaks every time my Windows 10 crashes)

Sometimes you have to lock your files away because other idiots kills you code over and over again. It is a nice thought that all developers are equal, but in the real world, 8 out of 10 do more damage to the project than improving.

I completely agree.

There is no excuse for development tools to suck. The intention is that they are simple to use instead of wasting time on keeping that damned, thing operating that you could have used to develop for your projects.

Good developers listen to the users, especially when people claim that it sucks. When users says it sucks then you as a developer have created bad work.

I am sick of UI that tries to help me and move content dynamically. It drives me insane when I click then I click the wrong menu item because it moved yet again the moment I clicked.

Only if I work 8/25/720. If I did not have a GF then maybe I could.

My problem is that everything that I have developed is hidden from view because it is created inside company walls and definitely not open Source.

SPAMMER

Fixed link

Great more freeloader SPAM.

What a crap. You don't become a hacker by following a course. Complete waste of money.

As a developer you should not learn one language but as many as you can get. Most projects are a mixture of languages within the same project.

OOP in the hand of idiots can bring your projects to disaster. And I have seen a lot of idiots. I actually have seen so many idiots that I wonder why after 25 years of OOP in the industry people still can't create good classes.

You have no idea how many OOP abuse I have seen. They wrap everything in classes but the classes are built the wrong way. They use it as a glorified namespace pretending to be OOP.

What a crap. If you want success, then stay away from companies like this!

Internally, Microsoft has been using a similar tool for about ten years now, Molnar told me. It’s been using it to detect potential bugs in Windows, for example.

Sometimes people wonder why software projects become worse and worse and worse..... This is why.

These are the tools that will be paid very expensive by managers so they can save on developers. But in the end this tool is just another pseudo tool that fails to deliver.

The thing is, that experienced developers are bing replaced by low quality workers and we are reverting to the dark ages. My concern is not that the quality of source code goes down. My concern is that this bad coding will end up in Nuclear power stations, self driving cars, medical machines, and kill people.

If you want to become a developer, then money is not your goal. All you want is to earn enough money, to keep in investing in technology to learn even more. If you do it for the money, then in a couple of years you will be very unhappy in that job.

What these schools don't tell you is that programming literally destroys your life in the long term. You are married to a job that is 365/7/24 for the rest of your working life. You job never becomes easy it stays hard all the time.

From career point of view: All of them.

I doubt that you will get a good answer:

• It would expose the code they used in their games, The last thing you want is the competition running with the ideas.
• It took years to figure out, knowledge means getting paid more, but when you explain it on the Internet then everyone can do it.

I think you will have to go the hard way, discovering it yourself and maybe find better ways.

The biggest question I have about big data is:

• How do you verify the quality of the data? (Faked, old data, obsolete data)...
• How do you know that the data is actually useful?

With small data sets you can easily test this, but big data is way too processes expensive and time consuming to verify.

Good information.

It is not clear what you want to do. But I assume you want to create dll's?

If you have Visual Studio and create a C/C++ application then you are basically already in Win32/64

Not everyone becomes a good programmer, not even after 30 years.

C# is the best starting point, it has a consistent framework that actually is build nicely and demonstrates how you should build your code too. If you design your code that it almost becomes exactly like the .NET framework then your project will become a success and be very scalable.

With C# I have built critical system, speedy systems, large scale systems, complex multi threaded systems, and the compiler is lightning fast. I get near C++ speeds too but I develop 100 times faster.

For very small projects it is a bit of overkill, but all my small projects have turned into big scaled applications over time. And project code turned into my own frameworks.

C/C++ is basically the same thing, just compiler that toys with the notation but under the hood it is the same end result. When you look at the assembler code then in case of C++ the first parameter is the reference to the object.

The big question is what do you prefer:

Save(fileHandle,"c:\foo.txt"); 

or

fileHandle.Save("c:\foo.txt"); 

OOP is nothing more that passing a pointer to a struct as a first parameter named "this." People already developed OOP code in C,

That WINAPI handle you have been passing on? It is basically OOP the only difference is its notation. Syntax sugar.

The field of IT have grown exponentially, and there are simply not enough skilled people.

There still are, but gets outnumber by less experienced people that will try to make their work even harder to complete. We are at a point where the new developers and project managers have no clue anymore what the experienced people are doing so they are fighting the people that are saving their projects.

It is heart breaking to see generations of new developers that have have mis-learned by these boot camps that will leave trails of failed projects in the years to come. It will eventually become better, but we have now 1 or 2 generations that will fail in their IT career. Once mis-learned it can never be undone.

Very nice information

My old computer was so badly shielded that a small radio near buy could pick up the signals. You could hear what the computer was doing. It helped in debugging.

If you want SCRUM to succeed then you must follow these steps;

• Do not create stories! Create fuzzy goals. The code will be written on the fly during depending in what is needed with the information you have now.
• No hard end dates, fuzzy dates that could be spread over a week. It is done when everyone feels that it is done. Not because time is up.
• Have at least one guy that is not confined to the SCRUM team. He must be able to roam free and look at the code and fixes bugs. This is a very vital person!
• No graph, no one wants to know how they are doing. That graph will only show failure and make anyone feel like losers yet again.
• Developers are not equal. Not everyone can do the development of that one guy. There is no such thin as all developers being equal.

Something ales that is also in line with SCRUM and Agile, that is Unit testing. The idea sound great until you start developing unit tests. It quickly becomes messy. So You become scared to develop new code scared to make some tests fail, so you end up with hacked code.

But worst of all, you trust the unit-test warnings. Green lights does not mean that your code is perfect. It might have huge design flaws but no one questions the code and fixes things because it would turn lights red.

Also

• SCRUM kills development. After a while you get so scared to change a thing risking to miss a deadline.
• SCRUM kills your development team, after a few sprints anyone will fight anyone because yet again the deadline was not met.
• SCRUM kills your project, quick hacks are implemented and there is no time to fix it.
• SCRUM makes the developers depressed. Every demo you realize that you failed again
• SCRUM is a beating stick for the business. You told them that you would fix it and you failed yet again.

I do develop in an very agile mode, but unlike SCRUM I develop out of sequence depending on what I need, if I am focused or sleepy, and if there is bug to hunt down or when everything works.I also use soft target dates, it does not matter if I reached it or reached it a week later. Once in a while you need a time to wrap it up as long as that date is not set in stone.

In the developers world, there is an artistic component. SCRUM kills that artistic component and you end up with bad results.

Hold on your high horses! I have been hearing lots of developers and and analysts now getting interested in SCRUM master courses. It is spreading like wild fire.

If you see a flashy site like this that is completely flashy but utter worthless to read, then you should question the content and especially question the competence of the company. If that company had good products then they would not try to hide it behind flashy web sites hoping you don't notice that they have nothing.

Jesus that site! Crappy as hell.

But so far .NET core is not being adopted by developers. It seems to go the way of the Dodo.

I do it 2 ways.

• Develop the code
• Try to comment what the function is doing.

If I have a hard time to write the comment what this function is doing then it indicates that the function is written incorrectly.

My end-goal is to have self documenting code. I design the code so that it helps intellisense. This removes comments-blocks from the code and you don't get distracted with comments noise that basically says the same thing as the real code.

If logging is used then I use the logging as the comment alternative. The logging should say what the code does.

Hot: GitHub

Not: Résumés

HR have no clue what to hire and they surely will have no clue what GitHub is. HR wants you to give them some excel spreadsheet that contains the number of years of experience for a certain item. Their choice in hiring you is just based how many bingo words you have written on your resume.

No one is going to look at your code on Github because no one that hires you will have a clue what they are looking at. They don't even understand if your code is good or completely bad. 10x developers will have big fights on Github to get their code committed. These fights are caused because 1x developers have no clue what you are doing. When HR looks at the discussion, they will favor the 1x developers since there are more of them and not hire that 10x developer that would actually make their project a big success.

Hot: Just-in-time education

Not: Four years up front

I see many developers that have a crash course in "Just-in-time education", their projects all end into failures.

Even seasoned developers can't create good solutions with "Just-in-time education". That never Works. Good developers already started years before to learn new technologies that may be used in the future. The moment they need it they already solved most of the issues before.

The fact that it is hot does not mean that the project will not end into tears.

But that is the hole point, how do you test that an AI is behind the fake searches. The AI adapts to new situations.

Maybe we do not need to pollute everything, just small enough that big data companies start to distrust the data..

Never going to work, people are completely fed up of advertisement. And I mean really really fed up with the intrusive nature.

Advertisement have brought me to a point where I never watch TV anymore, never listen to the radio anymore, and even stopped surfing to find new web sites. Any app that started with advertisement I uninstalled withing 10 miliseconds to a point where I barely use my smart phone since all my apps are gone.

I have absolutely no clue what you are talking about.

Maybe you should break it down first, so we can know what you are searching for.

I think neural networks would be great to do such a thing since it can learn and adapt. It is a low scale attack so big companies won't notice that their data is slowly turning into useless data. So it is not a massive flood of the data but a very slow crawling. I think the AI could learn by trial and error, and learn to outsmart big company AI's.

Maybe the AI could even generate a fake ID for you. Maybe convince Bing that you are Robert Redford.

Imagine that the AI also generate new photo's and upload them to new online profiles. The neural network AI's now in use really does not interpret images, but you can generate images with fake profile photo's that would fool a face detection AI (but not a human)

The key here is that is is a slow process, to go unnoticed. Slow gradual changes.

1. Analyze what the big companies have on you.

You need this to decide how to create query that will make that data less and less accurate. The advantage of a AI is that you let it run for weeks, months, years.

The naughty bit.

I use lower, makes it more human readable.

Update, when I started to take the challenge then I thought it would be simple but this simple example is behind the scenes pretty complicated. I don't think I can post this here on Voat nor have the time to create one. I estimate 3 working days for a first framework and then 2 more days to have a stable working version that can become the basis of anything direction you would like to take it.

In order to get a good basic frame you need to think about this.

• When I get the excel file is it one fixed template? Or a series of templates?
• Do the excel files come in pairs with the data and do I need to merge them?
• Is the data to merge fixed and do I have different excel files to merge?
• Do I have the merging data before the excel file? Or do I first need to load the Excel file and then determine what data I need from that file?
• Do we have a limited number of data files and excel files? Can I preload both of them?
• Can the data be already be preprocessed so that the merging takes minimal effort?
• Is the import files source the same as the output file source?
• Are the excel files huge? Os small size?
• Are the excel files and data files constant or changes on the fly?
• Do the cell data depend on each other?
• Do the cell data cross different tabs?
• Difference in file size? Bigger excel spread sheets need more time to load and save and can block smaller files that is waiting for the big one.
• Order of processing, are the excel files to be processes in the correct sequence as they come in or can this be a random order.
• The data to be inserted, Is it a simple push of data to known cells? Is it a search and replace of all cells?
• Testing, how would the users test every stage?

I surely would start with a separation of the Excel specific logic and and the processing logic. Design classes for an Excel subpart so that each part can be easily used.

If the excel template files are constant than I could is something like this: We prevent reloading the excel template every single time, just copy it reducing hard disk bottle neck

var mainTemplate=new Excel()
var isSuccess=mainTemplate.Load("Template.xls", MaxRetry:6, DelaybetweenRetries: 500)
if (isSuccess) {
      var datafiles=new DataFiles()
      var isLoaded=dataFiles.Load();
      while (isLoaded) {
          var newDest=new Excel(mainTemplate);  // Copy constructor that copies from the template files)
          var isProcessed=dataProcesser.Process(newDest))
          if (isProcessed) newDest.Save("destination.pdf", FileType.PDF)
      }
}
if (isSuccess.Close(KillProcessIfNeeded:True))

If data is not a search and replace the something like this can happen:

var mainTemplate=new Excel()
var isSuccess=mainTemplate.Load("Template.xls", MaxRetry:6, DelaybetweenRetries: 500)
var newDest=new Excel(mainTemplate);  // Copy constructor that copies from the template files)
if (isSuccess) {
     var datafiles=new DataFiles()
     var isLoaded=dataFiles.Load();
      while (isLoaded) {
          var dataProcesser=new DataProcessor(;
          var isProcessed=dataProcesser.Process(newDest))
          if (isProcessed) newDest.Save("destination.pdf", FileType.PDF)
      }
}
if (isSuccess.Close(KillProcessIfNeeded:True))

I don't have time to get in this project deeper but it is very interesting to solve it for my future projects.

I am in no way familiar with Excel automation but I would start with something like this.

What I do is start with something and observe how it behaves. Then I iterate through changes until find the most optimal code. This means that I will try different variations.

But before I can develop good code I must establish a base version that is simple and works. I don't care about fast or perfect, I must learn how Excel and OLE behaves, how it uses up memory, CPU, bottlenecks and how to recover from hanging first.

And most importantly the code should be readable. Note: I am doing this without C# just out of my head and I never developed for Excel ;-)

var excel=new Excel()
excel.Open("myExcel.xls");
excel.Close();

Stage 2

public Excel : IDisposable {
    public bool IsOpened {get; set;}
    public void Open(string fileToOpen) {
        ....
        IsOpened=true;
    }
    public void Close() {
        ...
        IsOpened=false;
      }
    void public Dispose(){
        if (IsOpened) {
            Close()
        }
    }
}

Stage 3 we get somethign like this:

using (var excel=new Excel()) {
    excel.Open("myExcel.xls");
    excel.Close();
}

Now we try a prototype not caring about bugs, naming or reliability. The goal is to have a concept, something that works just to find the weakness and flaws on this part

using Microsoft.Office.Interop.Excel;
public Excel : IDisposable {
    public bool IsOpened {get; set;}
    private Application exelHandle;
    private Workbook    workBook
    public void Open(string fileToOpen) {
           exelHandle = new Excel.Application();
           workBook = (Workbook)exelHandle.Workbooks.Open(fileToOpen, false, false, m_objOpt, m_objOpt,
                                                         m_objOpt, m_objOpt, m_objOpt, m_objOpt, m_objOpt,
                                                         m_objOpt, m_objOpt, m_objOpt, m_objOpt, m_objOpt);
        ....
        IsOpened=true;
    }
    public void Close() {
        ...
        if (wBook != null) workBook.Close(false, m_objOpt, m_objOpt);
        workBook=null;
        if (exelHandle!=null) exelHandle.Quit();
        exelHandle=null;
        IsOpened=false;
      }
    void public Dispose(){
        if (IsOpened) {
            Close()
        }
    }
}

I will continue in other posts (could take some time or days depending on my time I have)

But I think it is interesting to see my workflow.

Edit: Just a question Do you mean this:

* Open 1...n workbooks
* iterate through 1...N worksheets
* set parameters
* set formats

Or this

* Open 1...n workbooks
* iterate through 1...N worksheets
         * set parameters
         * set formats

No the robotics was a special year before the bachelor degree into electronics specialized in microprocessors.

Wow, I've never heard of that degree being offered.

That is because I was at the beginning at the robotics age and PC age. Yes I am that old!

And the fun part of all this, I turned full circle, I think the next decade I will be part of the next gen robotics revolution.

Robotics, electromechanical processing. No where near what I have been doing for ages.

I actually did not want to choose computer science, but my hobby became my profession by shear accident. I did not find a job and there was this tiny 3 man company that needed someone. And I was not supposed to be a main developer just a code monkey. They had a civil engineer just for that. But he left, and someone had to take it over and so it all started.

My concern if not the crappy consumer apps.

My concern that this crappy code is entering critical systems like industrial complexes, medical machinery, self driving cars, machines that processes food. We are at a time where deteriorated code can actually kill people.

I have 30 years of software development experience.

You basically invented the design patterns that are no in use but they remodeled in such a way that they became evil.

It is always funny that most young developers >10 years of experience thinks in absolutes.

• Either Waterfall or Agile, they have no concept of in between.
• Either design patterns or total chaos they have no concept of in between.
• Either all services or all local they have no concept of in between.
• Either top don or bottom up they have no concept of in between.

The real issue I have with Agile is not the method itself but that all too often management uses it as an excuse to cover it's own lack of management.

Exactly, or we know it is buggy but we will ship it anyway and fix it later (than never happens)

Clear separation of concerns were most likely not followed and now the monolith becomes the beast that must be fed.

Interesting wording but so true. It actually describes the real situation I experience. Without Agile I was 90% productive, then came rapid release cycles and I became 30% productive. Nowadays it is agile and I became 10% productive. 90% of my time is wasted to fix stuff that I could have fixed months ago by changing a couple of lines.

The only question I have is what exactly do you suggest as an alternative for the current age of development?

• Don't release code when time is up, but release code when the quality reaches a certain level.
• Deadlines are good, it forces the developers to clean up, but keep teh deadlines realistic and don't pin a fixed date. Give it a guidance date that can slip within reason.
• If you discover a bug then don't put it in a backlog top fix it next time. But hunt that bug down when it is hot until you got it. A random occurring bug is most of the time a signal of a design flaw.
• Stay away from "all developers should be able to do anyone else's job". Some developers are good in one thing but bad in the others. Don't force these good developers to do things they are bad in, and allow the good developers that are good in to do their specific stuff.
• Develop in zones. I both worked in projects whether developers had each their own part of the code and projects where every developer messed in the other developers code. The projects where everyone messed into every ones code became monoliths.
• The whole purpose of unit testing is to discover that a bug got introduced. But when I see at reality there is more code developed for Unit tests that could have been used in developing. You can perfectly create code in such a way that a bug introduced cause a red alert. Finding the problem is by reverting changes until you discover the exact point in time when the alarm got lit.
• If you do unit tests then make sure that the unit tests reuse as much code that is designed. It means that you will have to add code into your libraries that is friendly to unit tests.

I have been wondering why the software have deteriorated so much but I think the explanation is very simple:

• The market has been flooded by low quality developers
• The majority of the developers have less than 10 years of experience and no aware that different solutions also exist.
• Bad practice has been taken up by teachers and are now being taught in school to students. So bad behavior gets multiplied faster than experienced developers can compensate.
• Young developers lack the necessary skill to bring big projects to a success but since they outnumber the experienced developers they kick him out when he is yet negative again.
• Lack of trust. It is creepy to put trust in an experienced developer especially when he will do things that will go against your training and education. projects fail and get crippled when managers start to freak out and want to correct the experienced developer.

this is why hipsters shouldn't be coders..

I have to remember this one :-)

It would be nice if I know the scale of this project this is supposed to be. Are we talking about processing farms? Or are we talking about a single application that does these steps? Is it a batch script or is if a C# application? Does it run on servers without UI or just user PC's where the user can click on close when it messes up? Where do I get these source files from and where do the generated pdf files have to end up to?

Can I do the job without relying on OLE because the source files are in text XML? Not having to rely on an OLE server and processing XML content is way faster and controllable than using an OLE server.

I was already writing down a large scale solution until I realized that you are probably talking about a simple application. I am a C# developer, Batch script is not my specialty but heck why not. :-)

This was also based on WinForms which was quite current shiny UI back then.

When I started with it it looked so familiar, and it did Delphi 1.

That is so cool!

Don't ever tell what I say now in a hiring process! HR prefers you to use the "BINGO words" not what will make your project a success.

If you don't use well proved best practices in your program, how do you make it understandable for people that are not you?

Easy: the code looks very natural and reflects what you try to create

1- Design patterns are based on designs from good developers that solved a certain problem very well. However when academics try to quantity these design patterns and shoehorn them into some abstract way to designing software you basically killed the reason why this pattern was design in the first place: "To solve a specific problem and make your code readable"

The big problem now is that a lot of autistic idiot managers took a book learned the design patterns and for everyone to use these miracle saving solutions. And what make things worse every manager is now copying these other autistic idiot mangers without questioning if these design patterns makes stuff better or cause more problems than they solve.

Now why do people think that design patterns are miracle things? Because they are so used to bad design that no one knows anymore what a well design program look like. Developers are so used to see design patterns that no no notices that these are crippled programs.

2- This one is hard to explain if you never grew up with code that is elegant in design. Everybody has forgotten how to program. But I challenge you to kick out design patterns and unit tests, kick out agile development. And develop your program from scratch. Force your creativity as a develop to find new ways to solve a problem. Develop in such a way that your code becomes part of intellisense.

The key here is to force your inner developers creativity, break the development rules because you can.

If you are curious. If you could give an example of (short) design patterns then if I find time then I can convert it to something that is more elegant.

I design depending on what the program needs to do.

• The code is written in such a way that changes going to be located in one file if possible.
• The code is fault tolerant that if something happens it gets to a predictable state even try to recover.
• The code is written in such a way that it can be very easily tested by testers without need of unit tests or special tools.
• The code is written in such a way that it can be hooked into a UI but does not require one to run.
• The code is written in such a way that when it encounters a bug then it does not bring down the complete application.
• The code is written in such a way that it is intuitively User understandable and therefore I waste way less time in creating documents.
• The code is written in such a way that it optimizes the program flow first. If it needs speed then I design it for speed, when it needs reliability then I design it for realizability. If it needs user friendliness then I design it for user friendliness.

Now a wakeup call for anyone that uses design patterns! Design patterns sucks because it prevents you to create agile and easy to use/test programs.

Even critical sections should be avoided if possible. Every lock that fails adds stalling time and increases the chance that the next thread that wants to lock this part will end up waiting. It all depends of how long that code is locked.

Every lock in your code creates an expectational stall curve. Not having locks in the first place has a linearized the stall curves. Not having locks means that you have to rewrite your code and maybe use a bit more memory.

But every lock is a potential chance of a bottleneck. Writing your code in such a way that you have almost no locks is preferred.

In software you choose the tools and technology depending on your program you want to built. What is even more important in multi-threaded models is not asynch versus multi threaded but how you design your application.

Now how do you know which is better? You can't deduce it, you must measure it. And you can only measure it by building different variations of your code.

Edit: I want to expand on that. You build your code in such a way that you have small functions that can be used in both async and multi threaded solutions. If you create these functions thread safe (but avoid locks as much as possible) then you can use it in both systems depending on your needs.

I have no clue what this chart is supposed to show. But I can definitely say that C# did not exist pre 2000 and javascript not pre 1990s.

So I assume bad data?

• Everything is politics, it does not matter if you are a good developer or not, if you have to work with a boss that is less smarter than you or colleagues that are convinced that design patterns are the next coolest things, then you have to be very careful in what you say or do.

• Managers don't like smart too developers. They are burden because these expose the lack of knowledge of the manager. If you are a developer you must dumb yourself down. Once in a while let the manager find the bug.

• Race, if you get a new project race to create as much as code ass possible. It is the only way how a project will have a chance to become successful. The biggest reasons why projects fail is when the managers look a your code, don't understand what you are doing and freak out. When they freak out, then they will force you to follow the rules of some design pattern book they have read and sabotage their project.

• Failure makes to a better developer. Good developers learn from mistakes and improve their skills. The more mistakes you make the more you learn how your code can fail. In the end you will create a workflow that prevents you from making big mistakes.

• When you design code you must know what is the primary focus and a secondary focus. Your code is designed around these focus. The focus is always the end user in mind, never the design pattern or the syntax.

• You will never have the feeling that you have accomplished something. One of the crazy things in developing is that a well designed program is deceivingly simple and elegant in design. No one understands that this elegant design is very hard to cerate.

• Human resources. the art of bypassing Human Resources is basically trying to learn a list of hype words and bingo words. These people have absolutely no idea what they need and how they will find a good developer. For 2 years I failed every single job interview when I initially started until someone told me that I was never hired because I did not fit into their Excel spread sheet.

• Don't find excuses to explain why your code fails. Bad developers will blame anyone except themselves. And for some dark reason bad developers are favored in by Enterprise managers.

• Testers are your friends. If they report a bug then there is a bug that you need to fix. If it is something that cannot be reproduced, then realize that there is something there and you must find it. In a lot of cases it exposes a new series of bugs that you did not realize that it existed before. If for some reason testers incorrectly think that it was a bug then it indicates that you developed code that confuses the tester. The tester is not at fault , you as a developer are.

• Develop your code with testing in mind. Your code might become more complex, if it simplifies testing then in a lot of cases your code is elegant in design and probably will last for ages.

• Only release code when you feel that it is up to professional quality? It might not be perfect but you know that it won't blow up when a user looks at it. The mosts stressful periods are bugs that cripple the software and makes users call phone support. You will get burned out and never get a chance to develop anything for months.

• Expect quality from the testers. If you see them testing something badly then force them to have a higher standard. Force them to abuse your stuff, and even learn them how to abuse your stuff. One time I had a tester rename a .exe file to .txt and fed it to the input. It is hard abuse but it should not bring down a database or do other evil stuff.

Same C# program

using System;
namespace ConsoleApplication {
    class Program     {
        static void Main(string[] args)         {
            Foo1();
            Console.ReadLine();
        }
        private static string GetResult(int ix)         {
            var isFizz = (ix % 3) == 0;
            var isBuzz = (ix % 5) == 0;
            if (!isFizz && !isBuzz) return ix.ToString();
            if (isFizz && !isBuzz) return "Fizz";
            if (!isFizz) return "Buzz";
            return "FizzBuzz";
        }
        private static void Foo1()         {
            for (int i = 1; i <= 100; i++)  {
                Console.WriteLine(GetResult(i));
            }
        }
    }
}

The Human Resource safe C# version would be this:

        private static string GetResult1(int ix)
        {
            var isFizz = (ix%3) == 0;
            var isBuzz = (ix%5) == 0;
            if (isFizz && isBuzz) return "FizzBuzz";
            if (isFizz) return "Fizz";
            if (isBuzz) return "Buzz";
            return ix.ToString();
        }

But of course if you are a bit of professional you would create something like this which would fail the Human Resource test and you are not selected

        private static string GetResult3(int ix)
        {
            var isFizz = (ix % 3) == 0;
            var isBuzz = (ix % 5) == 0;
            if (!isFizz && !isBuzz) return ix.ToString();
            if (isFizz && !isBuzz) return "Fizz";
            if (!isFizz) return "Buzz";
            return "FizzBuzz";
        }

Why did I write it like this?

• Numbers are more likely to be returned than Fizz of Buzz
• Fizz is more likely be returned than Buzz
• Buzz is more likely returned than FizzBuzz
• Usage of "&&" is more compiler efficient

Be careful of this, software is not that black and white. I have seen a lot of developers that have this hard black and white thinking, but they created monsters. "Logical" monsters that on paper are perfectly designed but in reality are completely user unfriendly.

Software should be developed for a target in mind. Targets are users that will not follow your logic. A good designed program will reflect the user thought process in the code and may not fit your logic.

The other issues is that in software there is no one single answer; For any given problem you will encounter multiple variations that have the same end result. One solution would probably throw an exception and force the user to call service support to continue. The other solution could be less harsh, allow the user to enter an incorrect value during busy hours and later have the ability to correct when there is less stress.

No it is not, they are working instead of pointless meetings, status updates and demonstrations that they have done their work. And on top of that, no depressing graph that stares them in their face how badly they are performing.

At the age of 30 he will be sitting home with a burn out.

Why does /u/roznak keep posting so much anti-programming stuff in this sub all the time?

Because I see people entering things field that are not happy being a developer. But they are trapped there is no going back. Someone has to counter the "hype". This "hype" is drawing the wrong kind of people into the developers world. People that should never been there in the first place. They will create bad code, upset all other developers and become depressed themselves.

You don't need to go to any "bootcamp" either .. it is very possible to learn yourself

But this is completely different! These are the type of people that does fit into becoming a developer. Natural curiosity.

Also good developers are not going to be turned away from my negative posting. Good developers will say "Fuck you I will continue learning it no matter what you say."

Besides learning to code will actually improve your logical thinking skills.

I have news for you, except for tiny programs, there is no logic in the developers world. If you rely on logic, your programs will suck, because all the libraries out there are full of design flaws, full of bugs, and designed by complete idiots. "Creativity" to bypass the flaws and create solid solutions is more important that logical thinking.

hen suddenly you're no longer a passive victim of shitty lightbulbs bricking themselves because you refused a firmware update.

Ahhh the continuous upgrade cycle where every day you have 10 new updates waiting. That is not how you should develop professional software because it means that every day you are putting out a beta version of your software.

Updates should be rare because they are well tested before pushed. The reason is simple, at a certain point people get fed up with all these updates that happens daily that they don't bother to update anymore. I actually started to avoid these programs that have so many updates because I am fucking hating these yet another update that prevents me to use the application the moment I click it.

Something else, the key to become a good developer is not the course your got but the speed you can throw away old knowledge and relearn new knowledge within 1 month or less.

Just an example I had to learn Basica, USCD Pascal, Borland Pascal, Borland C++, Borland Pascal for Windows, Delphi, Visual C++ (MFC), Java, C# (Winforms, WPF, WCF, Services, LINQ, ASYNC,... ), HTML, Javascript, now Python.

While many coding bootcamps are legitimate and care for their pupils, an even greater number are run by modern snake-oil salespeople tapping into the average American’s desperation.

I have seen this in the photography too. SCAM artist trying to convince random people in the street that they can become models if they just pay them $600 for a photoshoot that they can use to go to a modeling bureau. The scam is that these girls pay big money for bad pictures and worse of all they would never have any chance in the modeling industry in the first place.

I see this SCAM now happening in the programming world. You will pay a lot of money to learn something that you will never be successful in. Programming is not for everyone. If it is not build into your very DNA, then you are going to hate being a developer. Being a programmer means 365/24/7 of none-stop learning. If you halt your learning skills for a few months then you become obsolete.

Right now when I am writing on voat I am also busy learning new coding skills. Becoming a coder means that you never will have a normal life.

It's built based on watching how factory workers work. It treats all developers as interchangeable cogs, not recognizing differences in talent

Exactly, it is basically killing talented people and force them to work like the worst developer in that team. I am forced to lower my standards otherwise the others won't understand. And if they don't understand what you are doing then your team members fight you. They try to "correct" you but in the end make it buggy and worse.

They force you to "commit" to things (but the team commits you for you so you don't really) so that you'll work harder because of psychological tricks.

It is exactly like this, it is just like cog workers to get your daily quota. And it is also a psychological trick. Because you gave estimates how long it would take, you are forced to deliver because you promised them that you would deliver.

"Officially", the scrum master should protect your from business when you slipped a deadline. But only a psychopath scrum master can handle enough stress to keep the team protected.

Good developers have a natural tendency to always create the highest quality of code in as efficient time as possible. Their reward is recognition and the fact that they did succeed.

SCRUM gives a constant feedback that you are a failure, and it is sabotaging your work because yet again you are in a pointless meeting while you could have reached that goal. It kills your good developers and makes them depressed or burn out.