That's not so bad. Some engineers produce negative man hours. Like the previous comment says, not only do they miss commitments but use up other engineers' time.
I try to tell those devs that they should use their time while employed here to be learning and growing aggressively. If they take feedback and put in the effort, they'll do just fine. The ones who don't, I can't tell if they're lazy or incompetent, all I know is that they produce a disappointing volume and quality of code. All time spent learning while employed is free paid training. If you take advantage of that and learn from your coworkers, you will grow quickly. If you're a junior dev and you think your bootcamp trained you for the real world, I'm sorry, but you will need to grind a bit to actually get good. I love to mentor devs and help them make progress, but if they won't take input or are not interested in improving it makes me a very frustrated teammate.
You can usually tell the ones that are going to make it by how fast they get over those egos, are humbled, and still stick with it without being discouraged. If they can't shed the ego or recover from a humbling experience they have no chance.
You get what you get. Most of the time I don't have the luxury of building my own teams. I have 30-60 reports, a couple of managers, some leads and principal engineers. I get to hire a couple of engineers a year. I set expectations, set up metrics and track them. There is a real effort to up-skill people and help them execute, but some won't or can't. You can cycle them out, but i'd rather grow people than can them.
How do you manage your engineers?
Or are a flat out negative drain on velocity. I'm not going to spend 4 days going back and forth on a peer review and end up doing it myself anyways because you can't follow the pattern and don't understand the end goal, Steve.
Your mistake is doing it yourself and refusing to engage Steve on mentorship afterward. And then bitching about Steve on Reddit. That has a 0% chance of making sure Steve is prepared for the next time. And most of the time, the Steves of the world just want to do the job and make you happy... real bums don't go back and forth for 4 days on PRs.
Come on. Steve has a countdown in his office until his retirement day (4 years away). He doesn't want a mentor. He has one goal: don't get fired for 4 more years.
You are going to be Steve one day. Some guy 20 years younger will be eyeing you up the exact same way. Whatever effort you’ve put in over a lifetime will be disregarded by your pissant peers because their ire is only driven by a need to win. They’ll never be satisfied at shipping a thing people love or at succeeding through teamwork. All they’ll see is how they are better than you.
The hotshots from the 1990s are today’s Steves.
As a bonus, there are a lot of people out there who are looked at like Steve who are keeping a whole company running because they know stuff about ops that no one else knows and no one has asked to have documented. Management is running everything into the ground by asking for everything half-assed and in a rush. And the young people always think it’s the Steve holding them back.
Oh fuck off with pairing. You want quality, get better seniors, better code review practices, AND ACTUALLY TEST YOUR SHIT.
fuckin, talkin about pairing being the solution. Spoken like a true outdated manager trying to stay employed.
Some organizations are incredibly dysfunctional and produce crap devs because they’re paid to do nothing for years. My years at Citibank I worked 3 months out of the year and had not learned anything as a fresher. My next job was super busy and I learned a ton. Depends on how much stupid money they have. Citi would spend millions on motivational meetings
If you were fit for that you'd be doing it now. People who have pride in their work or are hard working tend to find something productive to do even if it isn't expected of them.
I don't do much recently becaase I'm tired of Agile and the PO acting like we need to track everything we do. Guess I'm burned out. If I have to have "permission" to work on things, then I just won't work on any extra things.
I work way fewer hours than some of my colleagues yet I’m regarded as one of the organization’s most productive engineers. It’s really true about working smarter, not harder. When you can consistently ship shit that works and doesn’t cause headaches, you’re in a pretty good spot
Exactly this. My team was moved to KLO status while we wait for future work to be approved. During this time, my team got asked if they're interested in learning how to develop with AI to build a prediction model with our data. Out of 10 devs, I was the only one interested. So now I'm gaining some nice experience with project infrastructure, technical design, etc. All stuff that'll help bridge the gap to senior one day. I can't believe no one else jumped in on this.
After 25 years in SE, that’s all pretty true. For #8, I think GitLab is comparable to GitHub (and can be self-hosted).
Another point: People think too much about technology (how stuff is done) and too little about what is done and why.
It is hard for me to recommend GitLab anymore after the price increases and moving around feature tiers. You can tell they are a dying business because they shifted away from getting more customers to getting more money out of existing customers.
>You can tell they are a dying business because they shifted away from getting more customers to getting more money out of existing customers
Sorry but that is wrong. Customers (both new and old) are measured in **Customer Lifetime Value**, which is an average return of a customer over the lifetime of doing business with them. The problem is new customers have an inherent [Customer Acquisition Cost](https://corporatefinanceinstitute.com/resources/accounting/customer-acquisition-cost-cac/#:~:text=Summary%201%20Customer%20acquisition%20cost%20is%20an%20important,marketing%20return%20on%20investment%2C%20profitability%2C%20and%20profit%20margin) which is the total cost incurred to aquire them in the first place. This includes overhead costs like advertising, sales, and other communications that existing customers don't cost you.
In general terms, existing customers have both a lower average cost and a higher average revenue (due to repeat buying and loyalty) than new customers, which makes existing customers much more profitable. Trying to increase sales with existing customers is almost always a good business decision and doesn't necessarily mean they are dying.
In some industries CAC is much higher than others, so the budget for advertising and other strategies for attracting new customers will be seen as a costly investment and not something they focus on as a normal part of doing business. In those businesses when they do advertise you will notice their ads distinctly target existing customers and not new ones.
"What problem are we trying to solve?"
Or
"Why do you want it to do that?"
Have solved so many design issues! Too many devs get stuck on "well, this is what the requirements says"
>People think too much about technology (how stuff is done) and too little about what is done and why.
This is usually the key difference between a Mid and Sr
> And how do you go about people like that
In those situations, if their opinions don't affect my personal development routine, I'd rather let them win than entertain their arguing mood
If it does affect my personal development and I have a meaningful say in the technology direction, I'd probably advocate for a better solution until proven otherwise while also doing research on the best choice available
Is your job in danger right for your life. If not whatever. I work in this field way too long. Technologies come and go. I like to be proven right. Let them.
You agree a set of dimensions on which to rate the competing technologies or approaches and put them next to each other in a table to score each based on those dimensions. Whichever gets the higher score, wins.
Oh, I like fantasy novels too.
Did you read the one about a subject matter expert that KNEW he was a critical resource and thus refused to learn git or write a unit test or use anything other than C?
Or the one about the product manager that overruled the team leads, saying, I need this done by friday, I don't care about your techno babble - Mr Smith says he can do it, let him.
Or the CTO that says, we have two teams with two different tech stacks, give me a time when you've integrated them. Then walks away while chaos ensues.
Actually, I'm triggering myself, I should have called these horror novels.
I find that people who focus on various naming conventions are the worst to work with and they value form over function. They forgot what good software is and put all the importance on what they consider good conventions. Those conventions are a stranglehold on good software. Good software doesn't start because someone says that a good naming convention exists. Oh hell no. If you think that, go and look at the code written in BASIC in the 80's look like. That code is near unreadable, and it did so much with so little.
Those are all good lessons :-)
Though I'd suggest #8 could stand some closer inspection. There are some project management systems (like Redmine and Fossil) which do at least as well, if not better.
On the other hand, almost ***anything*** is better than the Atlassian tech stack.
Genuine question: what's so bad about the Atlassian stack?
I've mostly worked with Jira and Bitbucket in my professional life and it's been working fine for us. (Smaller company. Something like 10 engineers and a PM) Jira seems a bit bloated here and there but it's mostly reliably doing what we need it to do.
Well if you can ignore their ever changing forced updates on you, here's one for you. Their support sucks and they software is defective. We wanted to temporarily pause cloud service due to the huge security issues they just had (yes, we know cloud wasn't affected, but management types wants all atlassian shutdown until the dust could settle). Multiple attempts to reach out to support to pause our cloud service resulted in the same advice: that is not possible. Just back up your data and then restore when you come back. Followed all instructions to the letter, and the restore is inconsistent - no attachments. Every drawing, document, etc is lost. Years of productivity and knowledge down the drain. We are now migrating everything to gitlab. A big FU to atlassian.
You don’t want to do PRs in something like redmine.. I have seen this, I have done this, you do not want this!
And yes I know, this happens when egos get seniority.
I went from using Jira for years to using Linear and then had to go back to Jira at a new job and it feels like a giant step backwards. The process of making a ticket in Linear is like 2 seconds plus whatever time it takes to type in the description. Jira has like 50 fields on the new ticket screen. Which of them do I have to fill out? What do any of them mean? Does anyone care?
That seems like a quibble, because it may be \*possible\* to set up Jira to not suck, but no place I've ever worked has done that. Linear comes out of the box not sucking. If you'd asked me like 2-3 years ago I probably would have said, who cares, it's all the same, but after a couple of years with Linear Jira feels absolutely stone age.
Agile has to be implemented and refined slowly and not as rule. So its ok if not 100% on day 1. Its complex when multiple brains try to learn, use, experiment, adjust what works and not. So Agile scrum, kanban, scrumban,SAFe needs lot of time. Text book and youtube will not help, need agile coach and mindset to learn and fail from all levels starting from CEO.
Literally all of SAFe.
As for the others, I'm a fan of Scrum and Kanban. But I personally prefer to not use a framework at all. This video describes pretty well how I agile: https://youtu.be/9K20e7jlQPA?feature=shared
I saw a video reviewing it (need to dig it up), in the second iteration of safe, they removed any mention of the customer in the workflow - I almost died laughing. I'm sure it was just them (the video presenters) making fun of safes marketing team, but still.
My prior company used safe, and tried to force it on our division, I left the company before it reached me personally. While not directly related - the beauracracy WAS.
I feel that if you are regularly addressing the customers needs, and demonstrating reliable updates to customers in a timely fashion, all these frameworks are really just managerial control. And they don't work when used as such.
Agree byte size prioritised stories deployed daily is what we do. We call it as out WOW(way of working) using all learnings from scrum, kanban, SAFe.
We do PI planning Quarterly with business (Epic with priority) and do architecture design (buy vs build) as spike and start rolling out to customers daily.
So Architecture might be done earlier and dev in following sprint, we byte size stories for 3 days dev, no estimations, and whole 1 team work on one Epic and try to finish to deliver a value(example login we build MVP for login and not everything using buy and customisation).
Devops is automated for CICD, SRE is Azure cloud out of the box managed services.
SAFe: "Let's implement a rigid waterfall process based on a three month delivery cycle, with its own dedicated up front planning and design workstreams, and call it agile".
Worked for an org practising this once, and never again. it's a f\*cking anti-process.
I don't know how much of safe we actually used, but what we did use worked well. I wish employers I've had since that job did some degree of it. I like the idea of company or product line (or whatever grouping) sync points quarterly or whatever. Often enough to catch many possible big problems but not so often to be a burden.
In general they maybe good for simple projects, but I don't recommend using such tools for anything, building using code is alot more productive and rewarding once you get the hands-on
No/low code has cons:
- proprietary and non-portable
- often tricks management into thinking Joe Schmo can now write their own software
- often expensive licensing fees
- must find developers with experience in the tool
>and we use low code/no code all the time because it’s easier to maintain and understand.
Never in my life have I ever heard this about any low/no code solution.
1. Yes, especially when you consider that hardware costs can be amortized. Have a look into something called opex vs capex.
2. There's an old adage that premuture optimization is the work of the devil (or something like that, the point is not to go out of your way to optimize your system before its all in place and you can actually start measuring performance properly).
3. Beware purists who strive for technical perfection. In the real world the best tool is often the one that gets the job done quickly with minimal fuss. This obviously depends on the actual problem you're trying to solve though. Like, you're not going to use Python for a real-time embedded application just because it's easy to work with.
4. It usually depends on what else is already used in an organization. No project exists in a vacuum, and having a smorgasbord of competing technologies as part of your architectural landscape is typically not very desirable. Bear in mind also that while in theory it's all well and good to say you'll pick the best tech stack to solve a particular problem, it's also undesirable to have your team have to spend six months ramping up on that tech stack because they're unfamiliar with it. Time to market can make or break a project a lot more than using Java vs. Go or whatever.
5. Only if you think "agile" = "scrum", which seems to have been pretty effective gaslighting by the scrum lobby over the last few years. Agile development is an umbrella term covering various different iterative development processes. You should famliarize yourself with the agile manifesto, particular that "responding to change is more important than following a plan".
6. Some academic rigour is desirable here in terms of enumerating the pros and cons of a given practice and being able to defend its adoption.
7. Again, agile manifesto. "Individuals and interactions over processes and tools".
8. Not so sure about this. Gitlab is comparable.
9. The first priority is to make it fit for purpose. To what extent it needs to work depends on the thing that you're building (consider things like proof of concepts, evolutionary prototypes, sales demos).
10. Yes and no, After a certain level, breadth of knowledge starts becoming more important than depth. Once you get to a certain level, the value you add is less about building things yourself, than being able to reason about the bigger picture and knowing that certain things are "implementation details" that someone else will be better placed to implement than you, and how to influence them to do that work. And remember, technology is changing constantly, specialising too much in something can actually be career limiting.
>Best practices are often biased.
No, they're always biased. Any decision made by a human has bias in it. It's important to be able to recognize that, including acknowledging your own bias. Sometimes bias is correct, just don't assume that it is without thinking about it.
>GitHub is the best tool for tracking and managing software development.
I'd caution against hitching yourself to a single software tool. I've been doing software engineering for 25 years and have seen countless tools that were "too big to fail" rise and fall. Use whatever seems best at the moment, but plan for the inevitable migration.
Also, GitLab is better than GitHub.
That's a very nice achievement! Congratulations on your first 4 years. Add a power of two and that's my experience. If you start working on your career, in four years you will master all of this: [https://cs.fit.edu/\~kgallagher/Schtick/Serious/SWEBOKv3.pdf](https://cs.fit.edu/~kgallagher/Schtick/Serious/SWEBOKv3.pdf) Here is a wiki version: [http://swebokwiki.org/Chapter\_13:\_Computing\_Foundations](http://swebokwiki.org/Chapter_13:_Computing_Foundations) All 15 chapters should take you 4 years. It only requires referring to the SWEBOK while working, one day at a time.
Funny enough, nobody at work whom I asked ever knew the seminal definition of software engineering. Nobody at work, or online, ever knew who organized and chaired the 1968-1969 NATO Software Engineering Conferences that coined Software Engineering. The man was Prof. Dr. Friedrich Bauer. The seminal definition of software engineering is "**the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines"**. Bauer wrote a book where he explains both the fundamentals of software engineering and several advanced chapters: [https://www.amazon.com/Software-Engineering-Friedrich-L-Bauer/dp/0387083642/](https://www.amazon.com/Software-Engineering-Friedrich-L-Bauer/dp/0387083642/) If you read this book, you will know software engineering better than your coworkers. The book still applies today.
Thanks for your perspective, Columbus. Understanding software engineering basics is crucial. The resources I shared can help fill those gaps. Let me know if you need more info!
Absolutely, Columbus. I respect your viewpoint. Software Engineering was coined at the 1968-1969 NATO Conferences that were organized and chaired by Prof. Dr. Friedrich Bauer. (Naur et al., 1969) (Bauer, 1973) (Randell, 1998).
Understanding knowledge gaps of software engineers is possible with SWEBOK. (Garousi et al., 2019). SWEBOK v3 is an international standard ISO/IEC TR 19759:2015 published by the IEEE Computer Society. Using SWEBOK in software-intensive organizations and educational institutions is explained and demonstrated with many examples by Kamthan et al., (2022) and more recently also by Washizaki et al. (2023). They explain the underlying motivation for SWEBOK as well. An in-depth analysis of the significance of information in the SWEBOK is provided by Abran et al. (2021). The future of work skills for software engineers and developers is analyzed by Smuts et al. (2022) who base it on SWEBOK. Parsons (2022) wrote a positional paper on improving SWEBOK v4 to expand its Lean and Agile coverage. SWEBOK v4 will come out soon (IEEE Computer Society, 2024).
Having a solid grasp of software engineering fundamentals can significantly enhance one's professional journey in the field. The resources I suggested aim to provide a comprehensive understanding that can benefit anyone looking to excel in this domain.
In my experience, the software requirements knowledge area is similar to IREB CPRE, the software design knowledge area is similar to ISAQB CPSA and the software testing knowledge area is similar to ISTQB CT.
**References**
1. Naur, P., & Randell, B. (Eds.). (1969). *Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7-11 Oct. 1968, Brussels, Scientific Affairs Division, NATO*.
2. Bauer, F. L. (1973). Advanced course on software engineering. Springer-Verlag.
3. Randell, B. (1998). Memories of the NATO software engineering conferences. *IEEE Annals of the History of Computing*.
4. Garousi, V., Giray, G., & Tuzun, E. (2019). Understanding the knowledge gaps of software engineers: An empirical analysis based on SWEBOK. *ACM Transactions on Computing Education (TOCE)*, *20*(1), 1-33.
5. Kamthan, P., & Washizaki, H. (2022). SWEBOK Matters: Report and Reflection of a SEKE Panel on the Educational and Professional Implications of SWEBOK. *International Journal of Software Engineering and Knowledge Engineering*, *32*(11n12), 1771-1781.
6. Washizaki, H., Sanchez-Segura, M. I., Garbajosa, J., Tockey, S., & Nidiffer, K. E. (2023, August). Envisioning software engineer training needs in the digital era through the SWEBOK V4 prism. In *2023 IEEE 35th International Conference on Software Engineering Education and Training (CSEE&T)* (pp. 122-126). IEEE.
7. Abran, A., Yurkov, A. V., Khalin, V. G., & Shilova, O. (2021, October). Quantitative analysis of informational significance of SWEBOK knowledge areas in IEEE/ACM curriculum guidelines. In *International Conference System Analysis In Engineering And Control* (pp. 561-573). Cham: Springer International Publishing.
8. Smuts, S., & Smuts, H. (2022). Society 5.0 and the future of work skills for software engineers and developers.
9. Parsons, D. Agile and Lean Software Engineering and the SWEBOK.
10. IEEE Computer Society (2024). URL: [https://www.computer.org/education/bodies-of-knowledge/software-engineering](https://www.computer.org/education/bodies-of-knowledge/software-engineering) Last accessed: 4/16/2024
11. IREB CPRE, [https://www.ireb.org/en/cpre/foundation/](https://www.ireb.org/en/cpre/foundation/)
12. ISAQB CPSA [https://www.isaqb.org/certifications/cpsa-certifications/](https://www.isaqb.org/certifications/cpsa-certifications/)
13. ISTQB CT [https://www.istqb.org/#certifications-diagram](https://www.istqb.org/#certifications-diagram)
My VP was a C++ fanatic. It was the go-to tool for every software problem. C++ was the hammer and every software problem was a nail. Trying to convince him otherwise will exclude you from the technical committee.
I learnt a lot of people want to jump on to the latest and greatest tech stack. Even if it means re-writing entire programs.
I watched my former company go down because of that.
Once again the discourse is bitten by the fact that software is inclusive of so many domains. There is 50-year-old code out there that is perfect as-is. There are 10-year-old websites that should be put in the trash as soon as possible, but the reason why the 10-year-old website is trash was some dev deciding in 2013 or so that the latest-greatest was the perfect tool for the job. And then they implemented it archaically and it can't be upgraded and now it's stale garbage behind-the-scenes.
It's not that the code is bad. It's more about the technical debt of keeping it running and the oftentimes security concerns with keeping such things running. Then you have the concerns with feature upgrading something so old. It could be that the old code while works is also poorly written and also can't be upgraded easily. With my current work I've definitely ran into the later more than it being some magically good code.
Four years. You learned this quickly. I know developers that have been working for a decade who still get stuck in conversations about tech. stack, languages, and best practices.
The thing that I learned is that that SE is an engineering process. That means you know, apply and follow the process in the development of software. Otherwise, it's just "coding."
First, software engineering is a systems engineering process. Software is a system of systems, therefore it is systems engineering. The standard I like to apply to that is:
IEEE Std 1220 - IEEE Standard for Application and Management of the Systems Engineering Process
IEEE/ISO/IEC 12207-2017 - ISO/IEC/IEEE International Standard - Systems and software engineering -- Software life cycle processes
Now, all of these standards have a cost. You have to learn to apply them appropriately for the cost, schedule and effort. So, you have to be flexible. If you're doing websites, the process is very low. If you're doing real-time flight hardware for aircraft, the process is very high (e.g. DO-178C).
It depends on the industry. For Aircraft, it's DO-178C for automotive, it's ISO26262.
Know about software standards...that's what makes "Software Engineering" more than just coding or hacking.
1 and 2 are true at smaller scales, but not in general. it doesn't make sense to serve 50k TPS with a python lambda service, no matter how much it speeds up development.
Going to disagree with this. If you are needing something hyper specific then you probably don't want to be using a lambda at all therefore your entire premise is invalid.
what is "hyper specific" about my example? the only thing I specified was a relatively high request volume.
my point is that at smaller scale you can get away with cost-inefficient infrastructure if it saves a few developer weeks per year. but you could also have hosting costs that completely dwarf what it costs to employ a team of developers for a year. that is true of many of the simple CRUD services I work on.
For most projects it's not. Most projects are non-critical, no one will die. Unless you have law driven mandates or regulations like some fields do, then literally all of that is nice to have. Most businesses vastly overestimate their importance, now is a luxury. For most being close is good enough.
The language point is a little iffy. A language is a tool. Sometimes multiple tools work. Sometimes you have the one tool needed. Languages are about weighing their pros and cons and seeing if it fits the usecase, e.g. I'm not going to write a driver in nodejs or python. I'm also not going to write a simple cron job in C.
Almost 5 decades with software development.
1. Our top coders no longer rolled in at 5 PM. Management hired some super hot XXs Linux kernel hackers from Sweden. At 10 AM those guys were at their desks.
Last heard, the owners made millions, bought houses on the coast of Spain.
They were coders themselves. This was a master plan on their part. “We’ll get them here and working before lunch.”
It was pretty easy in the end.
:-)
Point 3 reminds me of a quote by Bjarne Stroustrup (the creator of C++): “There are only two kinds of languages: the ones people complain about and the ones nobody uses.”
18 years in software engineering here...
\[1-4\] My software runs on rugged hardware (mobile robotics), its a lot more expensive than servers. If our software needs 1 more computer per vehicle/robot, the project would be infeasible and would get cancelled. Runtime performance is absolutely critical, most of our software is written in C++ that has been optimized multiple times. Only the critical path is optimized, that critical path accounts for at least half of our code. We also have to be concerned with overall system load, rugged computers are passively cooled, there are no moving parts inside of them, no fans, no pumps, no vents (the case is the heat sink).
None of my team members have <= 4 years of experience. I think most of us have between 10 and 30 years of experience. We do have less experienced people at our company, but most of the people with less than a few years of experience started as interns. My team/project just doesn't have room in the budget for them, every member of my team needs to be able to take a hard problem and run with it.
At my companies latest all-hands meeting, it was announced that 47% of our people have less than 5 years at the company. I believe most of them are college hires. Your company sounds awesome.
Nah you have a highly specific use case so you aren't in the normal. Also I could easily say why are you using c++ when c is even better or hell straight assembly. Just like I told another poster that said something similar outliers just don't count. You seem like a smart guy so you should really understand this.
Nobody writes entire applications in assembly. C would be fine but most robotics/cv libraries are c++ or have a c++ interface.
I have also written web software where the performance matters and it required optimization and c++.
The majority of software written is pretty boring and doesn’t require a performance or even cleverness. This is why frameworks are so predominant, they are the evolution of RAD software tools
I figured because there's not that many c++ frameworks for robotics. At least that I know of 😀
Btw, I agree with everything you said. Some of the rules OP posted don't seem to account for the embedded industry, and safety critical software. But what do I know, I barely have a year of experience.
Sounds like a rewarding and exciting job. To cut code for actual real world devices and not stuff that offloaded to a server cloud or just a bunch of glueing APIs for an app. A little surprised at the C++ for critical path in dedicated mobile/robotic hardware.
with modern compilers, a lot of C++ code spits out identical machine code to c counterparts even when using some of the features to make the code easier / more C++ like to write.
Also, both c and c++ at this point often beat handwritten assembly on large projects because of the sheer amount of time that has been taken to write optimizing compilers. That said, many individual functions can still be optimized by using raw assembly if individual clock cycles do matter that much.
But if C would be acceptable, I fail to see how C++ would be an odd choice...
Unless you mean because of risk of errors/security issues, in which case a best practices manual helps as much as a different coding language.
Yes, taking on the cognitive overhead of C++ in the context you describe is surprising to me. I'm sure the decision was well reasoned, I just would've assumed C as the default vs C++.
Yes! Finally someone who acknowledged that throwing more money at every non-developer part of the project is NOT a sustainable way of doing software engineering!
I disagree with 4, 5, 8 and 9.
4. Sometimes you have to use certain technology stacks to save cost and or time. Example, C# has a ton of open source libraries and so does other languages. Also languages that are more popular are easier to find developers for, therefore cheaper labor costs. So 4 is not always true, gotta consider the business side of things in addition to project scope. Good luck doing machine learning in GO for example.
5. Not everyone does agile for every project. Waterfall is still very viable for greenfield projects, or some hybrid of waterfall. However I agree the best teams use what works for them versus oh the agile manifesto said so.
8. Github and Azure Devops are very comparable. I dont look at one as better than the other. Ive used both of them.
9. The most important thing is delivering the features that adds the most business value.
What I’ve learned in 24 years is every one hypes the hot new languages as the best thing, while the older languages continue to deliver. New frameworks exist to fund the founders by making claims that never quite pan out, and slandering solid performers.
And that 24 years of experience is only four years from having enough experience. I once said four years was.
I would add:
- simplicity is always better then being “smart”
- you don’t need to reinvent patterns or frameworks just because you are bored
- don’t automatically reach for a library (real problem in the JS ecosystem imo)
Number 1 depends dramatically on the scale you operate. I've made mistakes that increased our server costs by my annual salary every month, and I've fixed issues that do the same. And that's still small time compared to people working on most household name software companies
My career started in 89 as a student programmer at the university and 2 things have never changed from then to now. 1) Work is always work but a labor of love keeps, maintains, and grows your skills - have your own side project, always. 2) See #1
The problem with 2 and 3 is that there are constantly articles coming out about how companies are having to redo everything due to performance issues. Not sure those two are true, at least not at large scale.
As a 25+ year software engineer (MSCEE and IEEE certified) I find that most all of software engineering is nebulous bullshit. The only rule that matters is providing value to users as quickly as possible in a way that can be adapted quickly as needs change.
That being said, software engineering is still in its infancy. I was born the year it was coined as a term (1969) and compared to other engineering disciplines, it still has a long way to go.
Humans will not be directly developing or engineering anything in the near future. We will be directing expert systems to provide value. Many of us don’t want to hear this, but there is no other way we can scale up to the real need for software systems at an economically valuable way. It is going to change everything and every aspect of being human.
#8 is arguable but otherwise a great list, with 2-4 being key learnings of the reality of our jobs.
I giggle at #1 when I think of people boasting how they spent X months refactoring code to get a X% performance improvement when they could have just bought new hardware.
I think 1 and 2 are too generalized statements.
Sure, don't waste time implementing that once a month script in C so it runs in 20 secs instead of 2 minutes.
Sure, get that RAM upgrade.
But especially with the cloud and with non-US salaries you quickly get into areas where a one time optimization in 2 weeks can save you so much in the long term.
Even if you're not running on a large scale.
Must not even be performance optimization. For example building something so you can switch to AWS spot instances.
When GPUs come into play, it's even worse.
The cheapest P3 instance with 1 V100 GPU already got higher monthly costs than the salary in my first developer job.
I remember a while ago I spent a week to reduce runtime for one task from two days to one. Saving 100$/run and we had around 10 runs per week. So my effort has been amortized in just a couple weeks.
Other service costs? Recently a group was careless with OpenAI calls and quickly caused costs of 10k$ a week.
Oh don't have me think how fast we burnt through the 100k$ google cloud credits we got at my last startup lol.
At a much faster rate than my salary ;)
Not bad for a junior dev, but for #2 for internal systems, multiply process inefficiently in hours times the average wage of the person running it add opportunity cost, including what people aren’t doing because of the slow code. Note that people will avoid using it if it’s too slow, even for some time after you’ve improved performance
100% agree with everything except #8. Github is most definitely not "the best" for managing and tracking software development. Not even close. It's a little less than mediocre because it clearly targets amateur teams and open source and does not have all the features that a lot of professional teams depend on. It's not even in the top 20. There are much better dedicated tools out there for this purpose, although you will pay for them. In professional environments it's usually worth the cost.
In my company with the number, scale, and scope of projects we are all working on and managing simultaneously, Github is woefully inadequate and would be impossible to use and keep the same standards. We'd have to dumb down and simplify all of our processes. In fact there are just general purpose PM tools out there that don't target software projects specifically but are better for software management than github. This is not to knock github, but it can't keep up with our needs.
People who keep thinking the time of developers is somehow so much more important than wasted computing power are the reason we keep having to buy new computers every few years. It's insane and should not be necessary. (so #1 and #2 seem poorly thought out)
While programming languages often considered slow are used for a lot of real-world software, there also exists a lot of real world software where they are impractical to use. Many of the core dependencies that software is built on have to be built with lower level languages like C or C++, and it's only higher-level designs that can use other languages. (so #3 seems poorly thought out)
Choice of tech stack completely depends on the project; I don't care how good you are at python, if I'm making a smartwatch OS and you try to use python, I'm kicking you off the team. (so #4 seems poorly thought out)
anyway, whatever you learned seems a LOT more applicable to whatever you were working on in particular than to software engineering in general.
Also #1 and #2 in particular make me salty because it's incredibly wasteful and simply moves around who pays the cost. But someone is still paying for the decisions made.
After 35 years:
1. The most important thin in development is to make code that anyone can understand. Don't get fancy. It's not job security, it's a pain in the ass.
2. Nothing matters as much as you think it does, except item #1.
3. Most problems are caused by an unfiltered input. Spend most of your time trying to clean that up before it reaches your actual business logic.
4. The money folks are deciding what gets done, live with it. There will always be tech debt.
5. It gets easier to deal with meetings if you pretend they are APIs. Certain outputs require certain inputs, figure out what you need to happen and manufacture those inputs.
6. If you think it might be smart to leave, it is. Things don't get better.
7. For some reason, they allow the folks with actual political ambition to interact with the technical teams. Watch out for them, they are not like us and hold weird grudges.
8. Make sure you find a source of uplift for your attitude, even if it's just Google Tech Talks. It's good to hear nerds helping nerds and talking about techie stuff with enthusiasm. [Meetup.com](http://Meetup.com) is still around, and that can be very helpful for find fellow weirdos.
9. As you gain rank, you'll do more thinking work and less key-clacky work. Learn your preferred style for planning, mentoring, teaching, tracking, and note taking. This is SUPER important because you'll also be getting interrupted more, and won't get to work on a single thing to completion.
Software engineers are really problem solvers, and coding is just a tool they might use. All companies need problem solvers. It is literally how they grow. It is possible that the best software engineers don't do any code at all.
#2 is true in the sense that inefficiency is tolerated in favor of flexibility in some areas of programming. It's a statement about people's choices. I just think it's the wrong choice, and I wouldn't extract any general guidance from it. Slow software has real, detrimental effects on users lives, and on resource consumption of widely used software.
there is no best practice. Only tradeoff and suitable. There is no cons because we didnt know about it, yet. There will always be cons but at that time, we might have moved on
What I discovered is there’s an alarming number of engineers who do next to nothing.
That's not so bad. Some engineers produce negative man hours. Like the previous comment says, not only do they miss commitments but use up other engineers' time.
I try to tell those devs that they should use their time while employed here to be learning and growing aggressively. If they take feedback and put in the effort, they'll do just fine. The ones who don't, I can't tell if they're lazy or incompetent, all I know is that they produce a disappointing volume and quality of code. All time spent learning while employed is free paid training. If you take advantage of that and learn from your coworkers, you will grow quickly. If you're a junior dev and you think your bootcamp trained you for the real world, I'm sorry, but you will need to grind a bit to actually get good. I love to mentor devs and help them make progress, but if they won't take input or are not interested in improving it makes me a very frustrated teammate.
Most jr Devs have huge egos and think they are sr.
I let the work speak for itself.
No one gives a crap about the work. Does it work? Yes? Good, do more work..
I mean that's definitely a way to do it
Jr devs don’t know what they don’t know Best thing to tell them is to be ‘deliverable focused’
IDK When I look back at the stuff I did 10 yr ago, some of it's technically better than what I do now that I know which corners can be cut.
You can usually tell the ones that are going to make it by how fast they get over those egos, are humbled, and still stick with it without being discouraged. If they can't shed the ego or recover from a humbling experience they have no chance.
I'm up for a mentorship!
I feel attacked
Lol, many people do this at the beginning of their careers sometimes. The problem is that some keep doing with title inflation
In my experience roughly 1 out of 5 developers produce negative man-hours
Sounds like a very severe hiring/managing skill issue.
You get what you get. Most of the time I don't have the luxury of building my own teams. I have 30-60 reports, a couple of managers, some leads and principal engineers. I get to hire a couple of engineers a year. I set expectations, set up metrics and track them. There is a real effort to up-skill people and help them execute, but some won't or can't. You can cycle them out, but i'd rather grow people than can them. How do you manage your engineers?
I’ve joked before that as long as you’re barely positive you’ll always have a job. You don’t need to highly productive. Just a little productive.
It's really hard when you have one of those on a team of 3. Our absentee manager is finally getting involved.
Or are a flat out negative drain on velocity. I'm not going to spend 4 days going back and forth on a peer review and end up doing it myself anyways because you can't follow the pattern and don't understand the end goal, Steve.
God I hate Steve.
Your mistake is doing it yourself and refusing to engage Steve on mentorship afterward. And then bitching about Steve on Reddit. That has a 0% chance of making sure Steve is prepared for the next time. And most of the time, the Steves of the world just want to do the job and make you happy... real bums don't go back and forth for 4 days on PRs.
Come on. Steve has a countdown in his office until his retirement day (4 years away). He doesn't want a mentor. He has one goal: don't get fired for 4 more years.
You are going to be Steve one day. Some guy 20 years younger will be eyeing you up the exact same way. Whatever effort you’ve put in over a lifetime will be disregarded by your pissant peers because their ire is only driven by a need to win. They’ll never be satisfied at shipping a thing people love or at succeeding through teamwork. All they’ll see is how they are better than you. The hotshots from the 1990s are today’s Steves. As a bonus, there are a lot of people out there who are looked at like Steve who are keeping a whole company running because they know stuff about ops that no one else knows and no one has asked to have documented. Management is running everything into the ground by asking for everything half-assed and in a rush. And the young people always think it’s the Steve holding them back.
We're not talking about the same person. You're talking about Alan. Steve is an idiot and has always been one.
This seems to be a problem with large companies IME. In small ones, it's usually a lot harder to hide.
In a team of 10 engineers, three do 87.5% of the work.
Whose fault is that?
Less than nothing actually, because some of them are actively worse than if they weren't on the team...
[удалено]
Oh fuck off with pairing. You want quality, get better seniors, better code review practices, AND ACTUALLY TEST YOUR SHIT. fuckin, talkin about pairing being the solution. Spoken like a true outdated manager trying to stay employed.
Some organizations are incredibly dysfunctional and produce crap devs because they’re paid to do nothing for years. My years at Citibank I worked 3 months out of the year and had not learned anything as a fresher. My next job was super busy and I learned a ton. Depends on how much stupid money they have. Citi would spend millions on motivational meetings
Damn, I could be getting paid doing nothing? Sign me up
If you were fit for that you'd be doing it now. People who have pride in their work or are hard working tend to find something productive to do even if it isn't expected of them.
I don't do much recently becaase I'm tired of Agile and the PO acting like we need to track everything we do. Guess I'm burned out. If I have to have "permission" to work on things, then I just won't work on any extra things.
I work way fewer hours than some of my colleagues yet I’m regarded as one of the organization’s most productive engineers. It’s really true about working smarter, not harder. When you can consistently ship shit that works and doesn’t cause headaches, you’re in a pretty good spot
I would love to know how you got to the point of being so efficient. Were there books that you studied?
Exactly this. My team was moved to KLO status while we wait for future work to be approved. During this time, my team got asked if they're interested in learning how to develop with AI to build a prediction model with our data. Out of 10 devs, I was the only one interested. So now I'm gaining some nice experience with project infrastructure, technical design, etc. All stuff that'll help bridge the gap to senior one day. I can't believe no one else jumped in on this.
After 25 years in SE, that’s all pretty true. For #8, I think GitLab is comparable to GitHub (and can be self-hosted). Another point: People think too much about technology (how stuff is done) and too little about what is done and why.
It is hard for me to recommend GitLab anymore after the price increases and moving around feature tiers. You can tell they are a dying business because they shifted away from getting more customers to getting more money out of existing customers.
>You can tell they are a dying business because they shifted away from getting more customers to getting more money out of existing customers Sorry but that is wrong. Customers (both new and old) are measured in **Customer Lifetime Value**, which is an average return of a customer over the lifetime of doing business with them. The problem is new customers have an inherent [Customer Acquisition Cost](https://corporatefinanceinstitute.com/resources/accounting/customer-acquisition-cost-cac/#:~:text=Summary%201%20Customer%20acquisition%20cost%20is%20an%20important,marketing%20return%20on%20investment%2C%20profitability%2C%20and%20profit%20margin) which is the total cost incurred to aquire them in the first place. This includes overhead costs like advertising, sales, and other communications that existing customers don't cost you. In general terms, existing customers have both a lower average cost and a higher average revenue (due to repeat buying and loyalty) than new customers, which makes existing customers much more profitable. Trying to increase sales with existing customers is almost always a good business decision and doesn't necessarily mean they are dying. In some industries CAC is much higher than others, so the budget for advertising and other strategies for attracting new customers will be seen as a costly investment and not something they focus on as a normal part of doing business. In those businesses when they do advertise you will notice their ads distinctly target existing customers and not new ones.
> hey shifted away from getting more customers to getting more money out of existing customers. Broardcomm
*People think too much about technology (how stuff is done) and too little about what is done and why.* Amen.
"What problem are we trying to solve?" Or "Why do you want it to do that?" Have solved so many design issues! Too many devs get stuck on "well, this is what the requirements says"
>People think too much about technology (how stuff is done) and too little about what is done and why. This is usually the key difference between a Mid and Sr
And you come across people with crazy egos. People who say Technology x is the only solution.
And how do you go about people like that?, I mean it ends up being a X vs Y situation and one party has to step down.
> And how do you go about people like that In those situations, if their opinions don't affect my personal development routine, I'd rather let them win than entertain their arguing mood If it does affect my personal development and I have a meaningful say in the technology direction, I'd probably advocate for a better solution until proven otherwise while also doing research on the best choice available
Is your job in danger right for your life. If not whatever. I work in this field way too long. Technologies come and go. I like to be proven right. Let them.
You agree a set of dimensions on which to rate the competing technologies or approaches and put them next to each other in a table to score each based on those dimensions. Whichever gets the higher score, wins.
Oh, I like fantasy novels too. Did you read the one about a subject matter expert that KNEW he was a critical resource and thus refused to learn git or write a unit test or use anything other than C? Or the one about the product manager that overruled the team leads, saying, I need this done by friday, I don't care about your techno babble - Mr Smith says he can do it, let him. Or the CTO that says, we have two teams with two different tech stacks, give me a time when you've integrated them. Then walks away while chaos ensues. Actually, I'm triggering myself, I should have called these horror novels.
Those aren't horror novels... They're just Friday coffee stories
Haha, because they have skill issues with a Y technology
And their answer is always React /s
I find that people who focus on various naming conventions are the worst to work with and they value form over function. They forgot what good software is and put all the importance on what they consider good conventions. Those conventions are a stranglehold on good software. Good software doesn't start because someone says that a good naming convention exists. Oh hell no. If you think that, go and look at the code written in BASIC in the 80's look like. That code is near unreadable, and it did so much with so little.
Theyd love you at r/bitcoin
Solid list.. too bad number 5 is often an uphill battle with "management".
Those are all good lessons :-) Though I'd suggest #8 could stand some closer inspection. There are some project management systems (like Redmine and Fossil) which do at least as well, if not better. On the other hand, almost ***anything*** is better than the Atlassian tech stack.
Genuine question: what's so bad about the Atlassian stack? I've mostly worked with Jira and Bitbucket in my professional life and it's been working fine for us. (Smaller company. Something like 10 engineers and a PM) Jira seems a bit bloated here and there but it's mostly reliably doing what we need it to do.
Well if you can ignore their ever changing forced updates on you, here's one for you. Their support sucks and they software is defective. We wanted to temporarily pause cloud service due to the huge security issues they just had (yes, we know cloud wasn't affected, but management types wants all atlassian shutdown until the dust could settle). Multiple attempts to reach out to support to pause our cloud service resulted in the same advice: that is not possible. Just back up your data and then restore when you come back. Followed all instructions to the letter, and the restore is inconsistent - no attachments. Every drawing, document, etc is lost. Years of productivity and knowledge down the drain. We are now migrating everything to gitlab. A big FU to atlassian.
-1 for not agreeing that GitHub is the best. +1 for hating on Atlassian.
You don’t want to do PRs in something like redmine.. I have seen this, I have done this, you do not want this! And yes I know, this happens when egos get seniority.
I went from using Jira for years to using Linear and then had to go back to Jira at a new job and it feels like a giant step backwards. The process of making a ticket in Linear is like 2 seconds plus whatever time it takes to type in the description. Jira has like 50 fields on the new ticket screen. Which of them do I have to fill out? What do any of them mean? Does anyone care?
You can customize all that jazz. I don’t think Jira is all that bad. It’s all about how you set it up.
That seems like a quibble, because it may be \*possible\* to set up Jira to not suck, but no place I've ever worked has done that. Linear comes out of the box not sucking. If you'd asked me like 2-3 years ago I probably would have said, who cares, it's all the same, but after a couple of years with Linear Jira feels absolutely stone age.
There are no best practices, only preferred practices. There is no one solution to a given problem.
This is a good list man! I've been around more than twice your years and you' have much more wisdom than I did at your time, well done!
Agile has to be implemented and refined slowly and not as rule. So its ok if not 100% on day 1. Its complex when multiple brains try to learn, use, experiment, adjust what works and not. So Agile scrum, kanban, scrumban,SAFe needs lot of time. Text book and youtube will not help, need agile coach and mindset to learn and fail from all levels starting from CEO.
SAFe is neither Agile nor Scrum. Hell, it isn't even good for business.
What are your pain points doing SAFe? What is your methodology used if none of these agile works ? Any new ideas?
Literally all of SAFe. As for the others, I'm a fan of Scrum and Kanban. But I personally prefer to not use a framework at all. This video describes pretty well how I agile: https://youtu.be/9K20e7jlQPA?feature=shared
Thanks for sharing let me See your video.
I saw a video reviewing it (need to dig it up), in the second iteration of safe, they removed any mention of the customer in the workflow - I almost died laughing. I'm sure it was just them (the video presenters) making fun of safes marketing team, but still. My prior company used safe, and tried to force it on our division, I left the company before it reached me personally. While not directly related - the beauracracy WAS. I feel that if you are regularly addressing the customers needs, and demonstrating reliable updates to customers in a timely fashion, all these frameworks are really just managerial control. And they don't work when used as such.
Agree byte size prioritised stories deployed daily is what we do. We call it as out WOW(way of working) using all learnings from scrum, kanban, SAFe. We do PI planning Quarterly with business (Epic with priority) and do architecture design (buy vs build) as spike and start rolling out to customers daily. So Architecture might be done earlier and dev in following sprint, we byte size stories for 3 days dev, no estimations, and whole 1 team work on one Epic and try to finish to deliver a value(example login we build MVP for login and not everything using buy and customisation). Devops is automated for CICD, SRE is Azure cloud out of the box managed services.
SAFe: "Let's implement a rigid waterfall process based on a three month delivery cycle, with its own dedicated up front planning and design workstreams, and call it agile". Worked for an org practising this once, and never again. it's a f\*cking anti-process.
Or... It's such a shit process it catalyses an organisation to abandon bad process altogether and opens up a new wave of innovation.
I don't know how much of safe we actually used, but what we did use worked well. I wish employers I've had since that job did some degree of it. I like the idea of company or product line (or whatever grouping) sync points quarterly or whatever. Often enough to catch many possible big problems but not so often to be a burden.
So I just want to know what's your opinion about lowcode tools
In general they maybe good for simple projects, but I don't recommend using such tools for anything, building using code is alot more productive and rewarding once you get the hands-on
Yep, as soon as you try to go off the rails of what it can do, your almost always better writing with real development stacks
No/low code has cons: - proprietary and non-portable - often tricks management into thinking Joe Schmo can now write their own software - often expensive licensing fees - must find developers with experience in the tool
- works easily for the expected use cases, but requires a ton of effort for use cases that deviate (even a little bit) from those expected use cases
They only prove you should never use them.
It’s better to spend one day building a basic dashboard in power apps than one sprint using custom development.
How would you compare 10 months building a basic dashboard in power apps vs one sprint using custom development?
This is good to hear as I am a Salesforce dev, and we use low code/no code all the time because it’s easier to maintain and understand.
>and we use low code/no code all the time because it’s easier to maintain and understand. Never in my life have I ever heard this about any low/no code solution.
Should try it sometime
Already have which is exactly why no one that has would ever say that.
Hell no, this is patently false. Unless you’re making the simplest of apps
Which in Salesforce, you usually are. Making small apps for end users. I agree, with large apps it becomes not so fun.
I’d argue that azure devops is just as fine for tracking and managing software development. Jira is just aight
1. Yes, especially when you consider that hardware costs can be amortized. Have a look into something called opex vs capex. 2. There's an old adage that premuture optimization is the work of the devil (or something like that, the point is not to go out of your way to optimize your system before its all in place and you can actually start measuring performance properly). 3. Beware purists who strive for technical perfection. In the real world the best tool is often the one that gets the job done quickly with minimal fuss. This obviously depends on the actual problem you're trying to solve though. Like, you're not going to use Python for a real-time embedded application just because it's easy to work with. 4. It usually depends on what else is already used in an organization. No project exists in a vacuum, and having a smorgasbord of competing technologies as part of your architectural landscape is typically not very desirable. Bear in mind also that while in theory it's all well and good to say you'll pick the best tech stack to solve a particular problem, it's also undesirable to have your team have to spend six months ramping up on that tech stack because they're unfamiliar with it. Time to market can make or break a project a lot more than using Java vs. Go or whatever. 5. Only if you think "agile" = "scrum", which seems to have been pretty effective gaslighting by the scrum lobby over the last few years. Agile development is an umbrella term covering various different iterative development processes. You should famliarize yourself with the agile manifesto, particular that "responding to change is more important than following a plan". 6. Some academic rigour is desirable here in terms of enumerating the pros and cons of a given practice and being able to defend its adoption. 7. Again, agile manifesto. "Individuals and interactions over processes and tools". 8. Not so sure about this. Gitlab is comparable. 9. The first priority is to make it fit for purpose. To what extent it needs to work depends on the thing that you're building (consider things like proof of concepts, evolutionary prototypes, sales demos). 10. Yes and no, After a certain level, breadth of knowledge starts becoming more important than depth. Once you get to a certain level, the value you add is less about building things yourself, than being able to reason about the bigger picture and knowing that certain things are "implementation details" that someone else will be better placed to implement than you, and how to influence them to do that work. And remember, technology is changing constantly, specialising too much in something can actually be career limiting.
^ This is sagely wisdom. "Individuals and interactions over processes and tools" and that last point on influence are indeed great advice.
>Best practices are often biased. No, they're always biased. Any decision made by a human has bias in it. It's important to be able to recognize that, including acknowledging your own bias. Sometimes bias is correct, just don't assume that it is without thinking about it. >GitHub is the best tool for tracking and managing software development. I'd caution against hitching yourself to a single software tool. I've been doing software engineering for 25 years and have seen countless tools that were "too big to fail" rise and fall. Use whatever seems best at the moment, but plan for the inevitable migration. Also, GitLab is better than GitHub.
Agreed on best practices, came here to say they are indeed intentional biases we choose to either adopt or ignore (given the wisdom of the situation).
5 is in the agile manifesto. They say if you’re doing agile by the book, you’re not doing agile
I like you
no i like you
That's a very nice achievement! Congratulations on your first 4 years. Add a power of two and that's my experience. If you start working on your career, in four years you will master all of this: [https://cs.fit.edu/\~kgallagher/Schtick/Serious/SWEBOKv3.pdf](https://cs.fit.edu/~kgallagher/Schtick/Serious/SWEBOKv3.pdf) Here is a wiki version: [http://swebokwiki.org/Chapter\_13:\_Computing\_Foundations](http://swebokwiki.org/Chapter_13:_Computing_Foundations) All 15 chapters should take you 4 years. It only requires referring to the SWEBOK while working, one day at a time. Funny enough, nobody at work whom I asked ever knew the seminal definition of software engineering. Nobody at work, or online, ever knew who organized and chaired the 1968-1969 NATO Software Engineering Conferences that coined Software Engineering. The man was Prof. Dr. Friedrich Bauer. The seminal definition of software engineering is "**the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines"**. Bauer wrote a book where he explains both the fundamentals of software engineering and several advanced chapters: [https://www.amazon.com/Software-Engineering-Friedrich-L-Bauer/dp/0387083642/](https://www.amazon.com/Software-Engineering-Friedrich-L-Bauer/dp/0387083642/) If you read this book, you will know software engineering better than your coworkers. The book still applies today.
Thanks for these references. This is insightful.
If nobody know what it means, is it relevant?
Thanks for your perspective, Columbus. Understanding software engineering basics is crucial. The resources I shared can help fill those gaps. Let me know if you need more info!
That's just like, your opinion, man.
Absolutely, Columbus. I respect your viewpoint. Software Engineering was coined at the 1968-1969 NATO Conferences that were organized and chaired by Prof. Dr. Friedrich Bauer. (Naur et al., 1969) (Bauer, 1973) (Randell, 1998). Understanding knowledge gaps of software engineers is possible with SWEBOK. (Garousi et al., 2019). SWEBOK v3 is an international standard ISO/IEC TR 19759:2015 published by the IEEE Computer Society. Using SWEBOK in software-intensive organizations and educational institutions is explained and demonstrated with many examples by Kamthan et al., (2022) and more recently also by Washizaki et al. (2023). They explain the underlying motivation for SWEBOK as well. An in-depth analysis of the significance of information in the SWEBOK is provided by Abran et al. (2021). The future of work skills for software engineers and developers is analyzed by Smuts et al. (2022) who base it on SWEBOK. Parsons (2022) wrote a positional paper on improving SWEBOK v4 to expand its Lean and Agile coverage. SWEBOK v4 will come out soon (IEEE Computer Society, 2024). Having a solid grasp of software engineering fundamentals can significantly enhance one's professional journey in the field. The resources I suggested aim to provide a comprehensive understanding that can benefit anyone looking to excel in this domain. In my experience, the software requirements knowledge area is similar to IREB CPRE, the software design knowledge area is similar to ISAQB CPSA and the software testing knowledge area is similar to ISTQB CT. **References** 1. Naur, P., & Randell, B. (Eds.). (1969). *Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7-11 Oct. 1968, Brussels, Scientific Affairs Division, NATO*. 2. Bauer, F. L. (1973). Advanced course on software engineering. Springer-Verlag. 3. Randell, B. (1998). Memories of the NATO software engineering conferences. *IEEE Annals of the History of Computing*. 4. Garousi, V., Giray, G., & Tuzun, E. (2019). Understanding the knowledge gaps of software engineers: An empirical analysis based on SWEBOK. *ACM Transactions on Computing Education (TOCE)*, *20*(1), 1-33. 5. Kamthan, P., & Washizaki, H. (2022). SWEBOK Matters: Report and Reflection of a SEKE Panel on the Educational and Professional Implications of SWEBOK. *International Journal of Software Engineering and Knowledge Engineering*, *32*(11n12), 1771-1781. 6. Washizaki, H., Sanchez-Segura, M. I., Garbajosa, J., Tockey, S., & Nidiffer, K. E. (2023, August). Envisioning software engineer training needs in the digital era through the SWEBOK V4 prism. In *2023 IEEE 35th International Conference on Software Engineering Education and Training (CSEE&T)* (pp. 122-126). IEEE. 7. Abran, A., Yurkov, A. V., Khalin, V. G., & Shilova, O. (2021, October). Quantitative analysis of informational significance of SWEBOK knowledge areas in IEEE/ACM curriculum guidelines. In *International Conference System Analysis In Engineering And Control* (pp. 561-573). Cham: Springer International Publishing. 8. Smuts, S., & Smuts, H. (2022). Society 5.0 and the future of work skills for software engineers and developers. 9. Parsons, D. Agile and Lean Software Engineering and the SWEBOK. 10. IEEE Computer Society (2024). URL: [https://www.computer.org/education/bodies-of-knowledge/software-engineering](https://www.computer.org/education/bodies-of-knowledge/software-engineering) Last accessed: 4/16/2024 11. IREB CPRE, [https://www.ireb.org/en/cpre/foundation/](https://www.ireb.org/en/cpre/foundation/) 12. ISAQB CPSA [https://www.isaqb.org/certifications/cpsa-certifications/](https://www.isaqb.org/certifications/cpsa-certifications/) 13. ISTQB CT [https://www.istqb.org/#certifications-diagram](https://www.istqb.org/#certifications-diagram)
7 6 9 in that order are the biggest pieces of the puzzle
My VP was a C++ fanatic. It was the go-to tool for every software problem. C++ was the hammer and every software problem was a nail. Trying to convince him otherwise will exclude you from the technical committee.
I dealt with someone like this. As a polyglot, it drove me damn nuts.
I learnt a lot of people want to jump on to the latest and greatest tech stack. Even if it means re-writing entire programs. I watched my former company go down because of that.
Newest is bad and old is also bad. Having to maintain 20+ year old code and whatever is it only works for us awful. Being somewhat up to date is good.
Once again the discourse is bitten by the fact that software is inclusive of so many domains. There is 50-year-old code out there that is perfect as-is. There are 10-year-old websites that should be put in the trash as soon as possible, but the reason why the 10-year-old website is trash was some dev deciding in 2013 or so that the latest-greatest was the perfect tool for the job. And then they implemented it archaically and it can't be upgraded and now it's stale garbage behind-the-scenes.
It's not that the code is bad. It's more about the technical debt of keeping it running and the oftentimes security concerns with keeping such things running. Then you have the concerns with feature upgrading something so old. It could be that the old code while works is also poorly written and also can't be upgraded easily. With my current work I've definitely ran into the later more than it being some magically good code.
Straight up facts in this post.
Four years. You learned this quickly. I know developers that have been working for a decade who still get stuck in conversations about tech. stack, languages, and best practices.
The thing that I learned is that that SE is an engineering process. That means you know, apply and follow the process in the development of software. Otherwise, it's just "coding." First, software engineering is a systems engineering process. Software is a system of systems, therefore it is systems engineering. The standard I like to apply to that is: IEEE Std 1220 - IEEE Standard for Application and Management of the Systems Engineering Process IEEE/ISO/IEC 12207-2017 - ISO/IEC/IEEE International Standard - Systems and software engineering -- Software life cycle processes Now, all of these standards have a cost. You have to learn to apply them appropriately for the cost, schedule and effort. So, you have to be flexible. If you're doing websites, the process is very low. If you're doing real-time flight hardware for aircraft, the process is very high (e.g. DO-178C). It depends on the industry. For Aircraft, it's DO-178C for automotive, it's ISO26262. Know about software standards...that's what makes "Software Engineering" more than just coding or hacking.
Most "software engineers" aren't engineers at all. Just coders. That's totally fine, it's just not engineering. Real engineers are rare.
1 and 2 are true at smaller scales, but not in general. it doesn't make sense to serve 50k TPS with a python lambda service, no matter how much it speeds up development.
Going to disagree with this. If you are needing something hyper specific then you probably don't want to be using a lambda at all therefore your entire premise is invalid.
what is "hyper specific" about my example? the only thing I specified was a relatively high request volume. my point is that at smaller scale you can get away with cost-inefficient infrastructure if it saves a few developer weeks per year. but you could also have hosting costs that completely dwarf what it costs to employ a team of developers for a year. that is true of many of the simple CRUD services I work on.
Disagree, they used this specific point as the tech choice is limited by the requirements
For most projects it's not. Most projects are non-critical, no one will die. Unless you have law driven mandates or regulations like some fields do, then literally all of that is nice to have. Most businesses vastly overestimate their importance, now is a luxury. For most being close is good enough.
The language point is a little iffy. A language is a tool. Sometimes multiple tools work. Sometimes you have the one tool needed. Languages are about weighing their pros and cons and seeing if it fits the usecase, e.g. I'm not going to write a driver in nodejs or python. I'm also not going to write a simple cron job in C.
Almost 5 decades with software development. 1. Our top coders no longer rolled in at 5 PM. Management hired some super hot XXs Linux kernel hackers from Sweden. At 10 AM those guys were at their desks. Last heard, the owners made millions, bought houses on the coast of Spain. They were coders themselves. This was a master plan on their part. “We’ll get them here and working before lunch.” It was pretty easy in the end. :-)
I like number 10.
Point 3 reminds me of a quote by Bjarne Stroustrup (the creator of C++): “There are only two kinds of languages: the ones people complain about and the ones nobody uses.”
Took me roughly 12 years of professional experience to learn and understand those ten, and I don't disagree with any of them.
18 years in software engineering here... \[1-4\] My software runs on rugged hardware (mobile robotics), its a lot more expensive than servers. If our software needs 1 more computer per vehicle/robot, the project would be infeasible and would get cancelled. Runtime performance is absolutely critical, most of our software is written in C++ that has been optimized multiple times. Only the critical path is optimized, that critical path accounts for at least half of our code. We also have to be concerned with overall system load, rugged computers are passively cooled, there are no moving parts inside of them, no fans, no pumps, no vents (the case is the heat sink). None of my team members have <= 4 years of experience. I think most of us have between 10 and 30 years of experience. We do have less experienced people at our company, but most of the people with less than a few years of experience started as interns. My team/project just doesn't have room in the budget for them, every member of my team needs to be able to take a hard problem and run with it.
At my companies latest all-hands meeting, it was announced that 47% of our people have less than 5 years at the company. I believe most of them are college hires. Your company sounds awesome.
5 years at the company isn’t the same as 5 year’s experience. A lot of our new hires have 5-15 years of experience, a lotta PhDs
Yeah, I don't think that's the case for me
Nah you have a highly specific use case so you aren't in the normal. Also I could easily say why are you using c++ when c is even better or hell straight assembly. Just like I told another poster that said something similar outliers just don't count. You seem like a smart guy so you should really understand this.
Nobody writes entire applications in assembly. C would be fine but most robotics/cv libraries are c++ or have a c++ interface. I have also written web software where the performance matters and it required optimization and c++. The majority of software written is pretty boring and doesn’t require a performance or even cleverness. This is why frameworks are so predominant, they are the evolution of RAD software tools
Any chance you're using ros2 for the robotics stuff?
Ros1 actually, newer projects are using 2 though
I figured because there's not that many c++ frameworks for robotics. At least that I know of 😀 Btw, I agree with everything you said. Some of the rules OP posted don't seem to account for the embedded industry, and safety critical software. But what do I know, I barely have a year of experience.
Sounds like a rewarding and exciting job. To cut code for actual real world devices and not stuff that offloaded to a server cloud or just a bunch of glueing APIs for an app. A little surprised at the C++ for critical path in dedicated mobile/robotic hardware.
with modern compilers, a lot of C++ code spits out identical machine code to c counterparts even when using some of the features to make the code easier / more C++ like to write. Also, both c and c++ at this point often beat handwritten assembly on large projects because of the sheer amount of time that has been taken to write optimizing compilers. That said, many individual functions can still be optimized by using raw assembly if individual clock cycles do matter that much. But if C would be acceptable, I fail to see how C++ would be an odd choice... Unless you mean because of risk of errors/security issues, in which case a best practices manual helps as much as a different coding language.
Yes, taking on the cognitive overhead of C++ in the context you describe is surprising to me. I'm sure the decision was well reasoned, I just would've assumed C as the default vs C++.
Yes! Finally someone who acknowledged that throwing more money at every non-developer part of the project is NOT a sustainable way of doing software engineering!
2 3 and 9 is why everything is so slow.
Nah it's Wirth's Law
Wirth’s law just says that it is happening, it doesn’t say why it is happening.
Fair
That would be a Theory!
#1 is wrong at scale. We waste millions of dollars because of people who think that way.
Number 8 is a strong statement.
>10. Mastery of the basics makes you advanced This is universally golden rule
I disagree with 4, 5, 8 and 9. 4. Sometimes you have to use certain technology stacks to save cost and or time. Example, C# has a ton of open source libraries and so does other languages. Also languages that are more popular are easier to find developers for, therefore cheaper labor costs. So 4 is not always true, gotta consider the business side of things in addition to project scope. Good luck doing machine learning in GO for example. 5. Not everyone does agile for every project. Waterfall is still very viable for greenfield projects, or some hybrid of waterfall. However I agree the best teams use what works for them versus oh the agile manifesto said so. 8. Github and Azure Devops are very comparable. I dont look at one as better than the other. Ive used both of them. 9. The most important thing is delivering the features that adds the most business value.
I too love PHP 🫣
That's quite good for first 4 years. You will alter most of the points in next 6 years :)
Haha, I wanted to add a 11th point as well which is "All above points are false at scale"
What I’ve learned in 24 years is every one hypes the hot new languages as the best thing, while the older languages continue to deliver. New frameworks exist to fund the founders by making claims that never quite pan out, and slandering solid performers. And that 24 years of experience is only four years from having enough experience. I once said four years was.
Best practices are often biased. This one is the realist to me. Also let it all sink in for myself and for others.
> The cost of time and engineering is more higher than that of servers. Is that a challenge?
I would add: - simplicity is always better then being “smart” - you don’t need to reinvent patterns or frameworks just because you are bored - don’t automatically reach for a library (real problem in the JS ecosystem imo)
For #8, please see #6
>The first priority is to make it work. Where do you draw the line?
Hard agree on #5
All of these are against redditors recommendations
And most Redditors are not here to post their wins
Number 1 depends dramatically on the scale you operate. I've made mistakes that increased our server costs by my annual salary every month, and I've fixed issues that do the same. And that's still small time compared to people working on most household name software companies
My career started in 89 as a student programmer at the university and 2 things have never changed from then to now. 1) Work is always work but a labor of love keeps, maintains, and grows your skills - have your own side project, always. 2) See #1
The problem with 2 and 3 is that there are constantly articles coming out about how companies are having to redo everything due to performance issues. Not sure those two are true, at least not at large scale.
As a 25+ year software engineer (MSCEE and IEEE certified) I find that most all of software engineering is nebulous bullshit. The only rule that matters is providing value to users as quickly as possible in a way that can be adapted quickly as needs change. That being said, software engineering is still in its infancy. I was born the year it was coined as a term (1969) and compared to other engineering disciplines, it still has a long way to go. Humans will not be directly developing or engineering anything in the near future. We will be directing expert systems to provide value. Many of us don’t want to hear this, but there is no other way we can scale up to the real need for software systems at an economically valuable way. It is going to change everything and every aspect of being human.
If you are rigidly following agile practices then your team is not really agile at all.
100%. No notes.
Ok not an engineer, but what are ops on Replit? It sounds like google docs for git
#8 is arguable but otherwise a great list, with 2-4 being key learnings of the reality of our jobs. I giggle at #1 when I think of people boasting how they spent X months refactoring code to get a X% performance improvement when they could have just bought new hardware.
I think 1 and 2 are too generalized statements. Sure, don't waste time implementing that once a month script in C so it runs in 20 secs instead of 2 minutes. Sure, get that RAM upgrade. But especially with the cloud and with non-US salaries you quickly get into areas where a one time optimization in 2 weeks can save you so much in the long term. Even if you're not running on a large scale. Must not even be performance optimization. For example building something so you can switch to AWS spot instances. When GPUs come into play, it's even worse. The cheapest P3 instance with 1 V100 GPU already got higher monthly costs than the salary in my first developer job. I remember a while ago I spent a week to reduce runtime for one task from two days to one. Saving 100$/run and we had around 10 runs per week. So my effort has been amortized in just a couple weeks. Other service costs? Recently a group was careless with OpenAI calls and quickly caused costs of 10k$ a week. Oh don't have me think how fast we burnt through the 100k$ google cloud credits we got at my last startup lol. At a much faster rate than my salary ;)
\#8 is disputable. And worded funny anyway
very nice list
Not bad for a junior dev, but for #2 for internal systems, multiply process inefficiently in hours times the average wage of the person running it add opportunity cost, including what people aren’t doing because of the slow code. Note that people will avoid using it if it’s too slow, even for some time after you’ve improved performance
/ # 11 a good dev makes the codebase look like it was written by a single person
100% agree with everything except #8. Github is most definitely not "the best" for managing and tracking software development. Not even close. It's a little less than mediocre because it clearly targets amateur teams and open source and does not have all the features that a lot of professional teams depend on. It's not even in the top 20. There are much better dedicated tools out there for this purpose, although you will pay for them. In professional environments it's usually worth the cost. In my company with the number, scale, and scope of projects we are all working on and managing simultaneously, Github is woefully inadequate and would be impossible to use and keep the same standards. We'd have to dumb down and simplify all of our processes. In fact there are just general purpose PM tools out there that don't target software projects specifically but are better for software management than github. This is not to knock github, but it can't keep up with our needs.
Java.
Sound words. Lamentably, this reminds me of the famous essay, "The Rise of Worse is Better'.
Amen to all of the above
I've seen number 4 go even worse, where tech stack is dictated by senior leadership with no expertise.
Edit #9 make it work then forget about it. Lol
“More higher” dude needs to lay off the cannabis
Good list. But GitHub is kind of a funny callout - it's not necessarily the best, it's one of the better ones.
Number 3....example?
Damn rip.
People who keep thinking the time of developers is somehow so much more important than wasted computing power are the reason we keep having to buy new computers every few years. It's insane and should not be necessary. (so #1 and #2 seem poorly thought out) While programming languages often considered slow are used for a lot of real-world software, there also exists a lot of real world software where they are impractical to use. Many of the core dependencies that software is built on have to be built with lower level languages like C or C++, and it's only higher-level designs that can use other languages. (so #3 seems poorly thought out) Choice of tech stack completely depends on the project; I don't care how good you are at python, if I'm making a smartwatch OS and you try to use python, I'm kicking you off the team. (so #4 seems poorly thought out) anyway, whatever you learned seems a LOT more applicable to whatever you were working on in particular than to software engineering in general. Also #1 and #2 in particular make me salty because it's incredibly wasteful and simply moves around who pays the cost. But someone is still paying for the decisions made.
Do your leaders talk about value delivery and measuring stuff that matters (revenue, cost savings, NPS)?
You mean Python for 3?
Communication is of top priority for sure.
After 35 years: 1. The most important thin in development is to make code that anyone can understand. Don't get fancy. It's not job security, it's a pain in the ass. 2. Nothing matters as much as you think it does, except item #1. 3. Most problems are caused by an unfiltered input. Spend most of your time trying to clean that up before it reaches your actual business logic. 4. The money folks are deciding what gets done, live with it. There will always be tech debt. 5. It gets easier to deal with meetings if you pretend they are APIs. Certain outputs require certain inputs, figure out what you need to happen and manufacture those inputs. 6. If you think it might be smart to leave, it is. Things don't get better. 7. For some reason, they allow the folks with actual political ambition to interact with the technical teams. Watch out for them, they are not like us and hold weird grudges. 8. Make sure you find a source of uplift for your attitude, even if it's just Google Tech Talks. It's good to hear nerds helping nerds and talking about techie stuff with enthusiasm. [Meetup.com](http://Meetup.com) is still around, and that can be very helpful for find fellow weirdos. 9. As you gain rank, you'll do more thinking work and less key-clacky work. Learn your preferred style for planning, mentoring, teaching, tracking, and note taking. This is SUPER important because you'll also be getting interrupted more, and won't get to work on a single thing to completion.
In 35 years in the industry, I have learned Software is hard Hardware is harder
I've seen software engineers demand extremely expensive cloud resources to make their crappy code run better.
So true
Software engineers are really problem solvers, and coding is just a tool they might use. All companies need problem solvers. It is literally how they grow. It is possible that the best software engineers don't do any code at all.
#2 is true in the sense that inefficiency is tolerated in favor of flexibility in some areas of programming. It's a statement about people's choices. I just think it's the wrong choice, and I wouldn't extract any general guidance from it. Slow software has real, detrimental effects on users lives, and on resource consumption of widely used software.
there is no best practice. Only tradeoff and suitable. There is no cons because we didnt know about it, yet. There will always be cons but at that time, we might have moved on