constantine42

I see a lot of "government shouldn't interfere with the free market", but this is par for the course for Germany. After the world wars, they were in a do-or-die economic situation. The government started to heavily regulate and direct the industry that made Germany the power-house it is today. It's not perfect, but it has been working well for them so far. Enough to make them world recognized in many areas.

In my experience, there is little disagreement with how to solve a problem as with the problem being solved.

I've found that within the high performing engineers, they tend to agree quite often with the solution once they agree upon the priorities of features and the problems being prevented.

Development practices are not difficult to comply with because you make them work for you, not the other way around.

The issue that I see in software engineering is the XOR approach. Top-down vs bottom up, abstraction vs implementation. This is the wrong thinking. One of the classic books on software architecture said paraphrased "The architecture drives the implementation and the implementation drives the architecture". A classic book on software development said paraphrased "You design for the implementation you need and implement for the design you want.

It's a yin and yang. But many software engineers completely fail at this. They get stuck at implementation or design. You need both at the same time. They're trying to represent a many dimensional problem one or more dimensions lower than required. They're flat-worlders trying to describe a cube or even a tesseract. Of course there's going to be misunderstandings and mistakes. Everyone has a difference view of the cube. They're technically talking about the same thing, yet fail spectacularly when the parts don't quire align when they come together. The problem is very simple in a higher dimension.

It's like everything in programming. The 1% of the elite can use almost any methodology with great success, but the other 99% constantly fail to perform.

The problem solving aspect of programming is hard for most people. Nearly all of the high performers that I know are on the high functioning autism spectrum. They spearhead the hard technical problems, and set the stage for everyone else to tag along wit the busy work.

It takes all kinds to make a team, but we still need to recognize everyone's strengths and weaknesses.

And not every problem in programming is a technical problem. There are more issues in communication and understanding the problem being solved. Doesn't do much good to have a technically correct product that doesn't quite solve the problem.

What software engineering needs is a methodology in management to identify and properly utilize everyone to their unique abilities.

Lots of talk about false positives. As a human, when dealing with fuzzy logic, I like to focus on recognizing when something is wrong to reduce false positives.

Maybe Google should put more effort in training AIs to recognize when they don't know instead of shoehorning an answer.

An analogy is I would expect a non-stupid human who has never seen a screw before, but trained to work with hammering nails to quickly recognize something is wrong the first time they're presented with a screw and not attempt to hammer it flush.

Code smell, poorly factored. I almost never do this, but when I do, it's almost always because the code is already messy.

This can vary by problem domain and language. I see some examples of regex below and I can agree with that, because regex is difficult to read.

"sqs & kinesis"? These are two vastly different queuing systems. It's like saying "SSDs and Tape" are a better storage system than X.

I had the opposite experience. Old huge tank toilets got clogged and the new high efficiency ones don't.

100% "The trick is to not come off combative or argumentative". But I've never had to worry about "Tricking people into thinking something was their idea". It is always their idea, I just refine it.

I'm 15 years in and my PM puts me on special high profile cases, be it a new project or a failing one. She will literally tell the customer "We've got 'insert name' on this. He will ask a lot of questions and it may take him some time to complete, but rest assured that when he's done, it will be exactly what you need."

No pressure, right? I need to communicate very clearly about everything. If I feel there's a risk, I call it out EARLY. My PM wants to get out ahead of any issues and have all the resources that I need ready to go when I need them.

The upside of all of this is I have a "get out of jail" card. Because my PM and leadership know that it's actually done when I say it's done, they encourage me to take my time and do it right. Overtime, what's that? They know the mind fogs when someone works too much. I'll get scolded if I work too much.

Even when only working 30 hours a week, I find myself quite spent. I have no idea how people work 40-60 hours a week and still have the energy to go out and do anything.

The company I work for has an interesting setup. Marketing drives what products we need via marketing research, Product Owners(PO) represent those products and further research the problem space, Product Managers(PM) are coupled with an engineering team and the PM negotiates with the team around estimations, priorities, and planning. But ultimately the team decides what it does, but they are held accountable for delivering business value.

As a team, we can't just go all vigilante, but we can push back and have at times gone over other people's heads to make sure the proper people understood the problem. Most of the time we got what we thought was best for the customer by going over people's heads, but there's been plenty of times that a middle ground was reached.

The main thing is to not just say "we can't". Our job is to deliver solutions, not products. If there is a problem with priorities, we find an acceptable way to make things "work". Maybe that's adjusting timelines, or features, or just asking the customer how important that timeline is to them. I can't tell you how many times I've been told about "deadlines" that the customer never actually said was a deadline.

Us: Yo cust, can we slide that project 2-4 weeks?

Them: Sure. Heck, move it back 2 months if you want, but we absolutely need to start testing on our end in 3 months.

The problem with any outsourced companies is they live and die by acceptance criteria. Many times it takes longer to write out all of the criteria to the level of detail that I need than to just do it myself because natural language is horrible for such technical details and trying to explain to someone "What" and "why" is too time consuming.

It really bothers me because I generally get put on projects with little acceptance criteria and not something I've done before, yet I deliver on time and the end user is very happy because I take the time to ask good questions up-front. Why can't someone deliver something that makes me that happy.

On the topic of communications. I've consulted on projects where I've said that something I noticed should be done a specific way, even though it was not part of AC, technically worked correctly, and making the change would be feature creep. My advice was ignored. Weeks later the end users kept complaining that the software was difficult to use and could not communicate what they didn't like. Since they refused to use the software and they refused to accept it as it was, I was brought back in. I sat down, found out what work the end user was doing, and did some of that work. I literally did someone else's job. I used the software. I made a huge list of areas for improvement. The PM agreed to everything. All of the changes were made, the end users were now saying it was awesome to use.

To summarize, learn to read between the lines of the acceptance criteria. Would you want to use the software you're making? For me, small issues annoy the heck out of me. I notice these things. End users tend to just say nebulous things like "it doesn't work well".

It's funny to say, but I can't agree. I've designed and implemented many custom systems for which there was never a predecessor, and not only did it work splendidly at first release, but have been extended and enhanced many times over the years with no refactoring. Many of these systems have been extended enough to start taking over other systems that were never intended.

Design a system to be modular from the very beginning with only the most fundamental of API signatures and you win. Many of these signatures may even no-op for years, but because they're fundamental to the problem, you know there could be a case where they're needed.

I've never had a failed or late project and most of my projects are ones that were assigned to me because no other team would touch them due to all of the attention and required SLAs.

"Grind" your way into good architecture? Good architecture is designing, not trial-and-errored. The only grinding I do is mental before I type a single letter of code.

I don't follow you. I need an ID to get a voters registration card. You already need an ID to drive, vote, bank, work, rent.

Good ole double buffering. I've used this pattern for many custom concurrency designs.

Useful redundancy is a continuum. On one side is adding "unnecessary" null checks. On the other side re-implementing complex business logic checks. I like to strike a balance.

"Overspeced" unit tests? They should only be testing the API contracts and all edge cases. And refactoring your code should not result in changes to the unit tests as the purpose of the unit test is to tell you if your refactoring broke something. If you have to change your unit tests when you refactor, you're doing something wrong.

Fighting unit tests is a code smell for testing implementation details or poorly designed API that needs to keep changing.

I've been bitten by "clearly impossible in the context of the whole system" way too many times. That said, I'm not going to do horribly complex implementation detailed validation. But sanity checks are worth their weight in gold.

Yes and no. Testing is a very important part of agile, yet if you don't have a somewhat final internal design, you will find yourself changing your unit tests every time you refactor your code. As a rule of thumb, changing your unit tests is a no-no.

First off, it means your code is brittle. Second is that you can't trust tests that must change every time your code changes. Might as well not even have them.

Unit tests are supposed to tell you if your refactoring is still working. For the most part, you should only refactor implementation details, not the "API".

There is also a design to uncertainty trade off. The less you know about something, the less time you should spend designing because you can't design something you don't understand. But the more your understand something, the more time you should probably spend designing.

Knowing how much design is too much is subjective and personal. I forget where I read it, XP(Extreme Programming) or Code Complete, but someone worth listening said, to paraphrase, "I've never regretted spending more time on design before I started coding". And I'm pretty sure it was part of XP that said the main purpose of XP(Agile) is to deal with the unknown. The more you know, the less Agile and the more waterfall you should be, saying that for some projects, a 6 month sprint is perfectly valid.

I am in an interesting situation where I am both the programmer and the domain expert. Generally customers come to our team describing a problem that other companies can't figure out. We're pretty much allowed to design everything how we feel like because we're the best at it. We can do virtually any project in a single go of it without feedback from the customer, but we still do agile because it helps with scheduling, planning, prioritization, etc.

We're a "value add" team, which makes things really interesting. None of our work is sold, but the work is important to land large contracts for the companies core services.

Jira can be highly customized. I find it easy to use for day-to-day. I also have to deal with Jira with a subsidiary company, and their Jira is completely different, but it works well for their use case.

The reporting is a whole other issue. I don't use this, but my PM does because upper management keeps changing their reports and my PM has to keep linking and organizing. But as a developer, doing spring planning and burndown charts work quite nicely.

Where I work, all teams have different point systems. When we need to do high level planning, we used a normalized "sizing" system of small, medium, large, huge. They give some numerical values to these and use those as points. They're less accurate on a per story basis, but they tend to average out quite well.

I don't entirely agree with this article, but I do understand its merits.

When I was really young, around 8, I didn't have books, TV, and the internet wasn't around. I spent much of my time thinking about computers because I saw them once and was fascinated by them. One of the thoughts I had was about multi-socket computers. How did the two CPUs communicate and run in the same system.

I eventually came up with the concept of race conditions, but I had no word for this concept, but I could see it in my mind's eye. I eventually thought of different ways to work around race conditions by making certain assumptions.

Nearly 2 decades later I was in my first job when a CPU bound problem showed up and I quickly slapped together some multithreaded code that worked the first time and was not only the first time I ever wrote multithreaded code, but was also my first real world programming project. I hand rolled a lockless queue. It was messy, it had some redundancies, but what I wrote was based on the concepts that I thought about when I was 8 years old.

It was at this point that I decided to look into my concerns about "data access ordering multithreading" and learned about the term "race conditions".

Of course learning this term opened up my mind, furthering my understanding of the concept both in communications and in more concrete concepts than the abstract blurs in my mind.

I actually deal with unknown unknowns all of the time. When I envision a problem in my head, I tend to focus on guarantees. I enumerate assumptions that my designs require, and if I can't prove to myself that I can guarantee that assumption, then it is now a known unknown.

I have a track record at my work of finding corner cases. I do this entirely by my "guarantee" approach. If I can't guarantee something, can I think of a proof of concept that could cause the assumption to be violated. This also works well for multi-threading. I don't need to worry about thinking about a problem in a serial fashion, I only have to think about "in order for this to work, what assumptions do I have to make and can I prove those assumptions."

It's quite often that I learn about new concepts by describing an assumption that I can't guarantee, and I will find an existing answer or solution.

I've reflected on my obsession with correctness. I've found my issue is my ADD. If I can't prove something can't happen, my mind will wander uncontrollably thinking of what might go wrong. In order to cull these distracting rabbit trail thoughts, I have to prove to myself that no issue can occur.

This approach works well enough that I've had large complex mulithreaded projects where the process deadlocked several times. When the problem got priority and my team lead asked me if I had any ideas, I told him "I read thought my code, it must be .Net framework". He thought I was joking at first. Three times in a row, non-reproducible deadlocks that rarely occurred, I diagnosed as "not my code", and 3 times I was correct.

Not only does this process seem to work well for me, but I've also used it with other's who were stuck pair programming a bug that they couldn't figure out. I can generally just start asking questions and eventually the programmers figure it out on their own.

I think if more people focused on guarantees, there would be fewer issues.

Where was I? Oh yeah. If you can't guarantee something and you can't figure out why, then there must exist an unknown. You don't need to know what this is in order to know it exists. Having a word for it helps tremendously, but it is not required in order to reason about it.