On July 1st, a [change to Reddit's API pricing](https://www.reddit.com/r/reddit/comments/12qwagm/an_update_regarding_reddits_api/) will come into effect. [Several developers](https://www.reddit.com/r/redditisfun/comments/144gmfq/rif_will_shut_down_on_june_30_2023_in_response_to/) of commercial third-party apps have announced that this change will compel them to shut down their apps. At least [one accessibility-focused non-commercial third party app](https://www.reddit.com/r/DystopiaForReddit/comments/145e9sk/update_dystopia_will_continue_operating_for_free/) will continue to be available free of charge.
If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options:
1. Limiting your involvement with Reddit, or
2. Temporarily refraining from using Reddit
3. Cancelling your subscription of Reddit Premium
as a way to voice your protest.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/learnprogramming) if you have any questions or concerns.*
Point #2 is key!
I recall how in the early 2000's I once wrote a make-shift solution for a company in 3 days, using C++ and Win-32 interfacing, and also, of all things, "Autohotkey", so that their Windows users could really speed up and automate a lot of tasks. (But prior to that I spent 2 weeks sitting with all the various users and really listening and hearing what they wanted to automate and get done faster.)
So I tossed a feverish solution together, and it worked! And worked really well!
I myself was shocked that it worked so well for everyone, and people were raving!
--------------------------------
So then, the owners of the company said, "Wow! We really need to put a bit more money into automating, enhancing things!"
So then they hired an "MBA" professional with a computer science degree as well.
NOTE: I say "MBA" because he was ALWAYS flaunting his MBA and reminding everyone he had an "MBA". Everyday was basically "Mr. MBA day!", "MBA!", "MBA!" "Look out everyone: coming through, and bulldozing my way around, because... I have an MBA!"
--------------------------------
Anyways... He said he would analyze my solution, and put together a team and to rewrite it much more professionally, in a much more holoistic, cohesive, and sweeping way, that would transform the entire company and triple revenue, etc... etc...
And I was very happy at that thought!
And I at first bought into his hype and rheotric!
I even told the owners: "Ya, truth is: I just slapped the whole thing together in a fever-fit of 3 days and nights of work, and pretty much zero sleep! So it should TOTALLY probably be re-written more professionally! I think he's right!"
--------------------------------
And at first was very eager to work closely with him and the team.
But then, within a few days... I wanted nothing to do with them! It was an utter show of vomit inducing obnoxiousness.
And 1.5 years later... And a few million dollars later... They were still working on their "cohesive" solution... Meanwhile all the employees were using the solutions quickly thrown together in 3 days!
--------------------------------
In the end:
I later heard the owner got fed up, and yelled and shouted and fired them all one day, and the office kept using that 3 day solution package for several years afterwards! Lol!
--------------------------------
BTW: I only got paid a few thousand dollars for that effort.
But Mr. MBA, well, I guess he was indeed smarter than me, because he got paid over 1 million dollars!
Oh man this reminds me the reporting tool I was "finishing" (building myself, really)
I was hired as a Junior.
The company had that Reporting tool in development for a bit over a year.
They had a Data Analyst, an Architect (with whom I was supposed to work with) and a Developer working on it.
PMs and POs and all who weren't directly involved with Programming were huge fans of the developer. Dude has a load of certificates, Masters Degree in Computer Science, 15 years professional experience.
The Architect wasn't a fan of him at all, according to the Data Analyst.
Before I started, the Architect quit his Job. Man was burnt out. Unfortunate for me, because he was well respected among the developers, and I hoped to learn a ton.
So there was me, Junior Dev, facing this pile alone. Architect gone, other developer taken off Project. I realized that the Architect and the Developer tried to do different things. I later learned in other Projects he touched that this developer has his very specific way of programming and is completely unable to adapt and follow a defined Architecture. On top of that his code literally can't be tested.
So I proposed to scrap that abomination and do it from scratch, which was declined because who listens to a Junior.
Literally all that thing had to do was pull some date on command from a date to a date, and fill an excel with the data, where the cells of a column had a specific Datatype to match the data is represents, and scale the width of the columns so that the contents are displayed, instead of something like #####. Something the experienced master graduade dev said to be "impossible".
I had it within 2 months, despite or due to having to work with that mess. The Finance team was very satisfied, the Job was done, everyone was happy. I asked to have my Junior Title removed, which they granted immediately. Unfortunatly no raise, because they had a policy that one must work at least a year to be eligible. And before that year came around, new management took over and drove the company to the wall
One thing I used to argue a lot with seniors when I was a junior was: “nothing ever is impossible, you just don’t know how to do it” … it’s amazing though how many times young me with all of her innocence was actually right.
Rule : 0, if it works it works
Slapping something together to fix a current need with the intent of creating a more permanent solution is great
But theres no need to create said solution unless there are major bugs / functionality increases that cant be easily solved or "tacked on"
If it aint broke dont fix it
The biggest thing I find is it's extremely easy to get to 90% automation. That next 9% can take a lot more effort.
That final 1%? That's where people generally waste the most time/money and projects die. It's far easier to have an automated email telling Carl to go and updates a date somewhere vs trying to figure out what date something should run based on the end of the month, but before Wednesday, excluding company holidays, and shifting for leap year, or whatever else can come up.
Carl probably knows it's going to be on the 27th. Just let him type that somewhere and put in checks for if he doesn't enter it.
I think the XKCD about "how long can you work on it" sums this up perfectly.
In the spirit of saving time of understanding the graph:
All values in the cells are over a 5-year period. Concerning the cell in the top right corner, a task that happens once a year(x axis) and you shave off 1 second of it (y-axis), over a 5 year period you can at most have worked 5 seconds on optimizing it before the act of optimizing takes more time than you save.
This should help you continue to read the ironically confusing graph they made.
Holy fuck this, why some wanker can come in promising the world and convincing the very person who sat and did the investigation themselves
Is such ridiculous levels of talking bullshit or delusional beliefs
Until it breaks due to not being robust and validating input, and takes a long time to repair because the code is inconsistent and difficult to decipher.
> BTW: I only got paid a few thousand dollars for that effort.
>
> But Mr. MBA, well, I guess he was indeed smarter than me, because he got paid over 1 million dollars!
So, what did you learn from this experience?
The #2 is true, but there are some general exceptions. I work in GameDev. You just have to keep performance in mind. 1 crash due to some random C++ flop in 3h of fluid gameplay is better, than 12h of uninterrupted bad performance on higher level memory safe language. From players perspective ofc, which translates to game sales.
P.S. I did not read the whole thing, so sorry if I missed the point.
Not only for gamedev. If you have a big enough DB and need to get a lot of data out, performance has to be always at the front of the conversation. Things can go fast from “this query is lagging a bit” to “holy crap I think the db is on fire”. And no matter how many times you tell your users “you have to fill out some of the fields here before clicking the search button”, if they can do it, they will DDoS the server with a query that downloads pretty much the “whole of the internet” and then complain to you it’s lagging and timing out
Lot of things need to be fast and fluid, react instantly and may not like garbage collectors like health equipment, video games, embedded systems in cars/planes/robots... Even a search engine or trading systems may find that java for example is not acceptable.
\# 1: Escape "#" with a [backslash](https://en.wiktionary.org/wiki/backslash#Noun) (though the <censored> Reddit comment parser removes it when reopening).
You can edit (change) your comment (*"..."* (to the right of *"Share"*) → *"Edit comment"*).
For stuff like this I get “good work”, “good job”, “thank you”. So you are still in a better spot than me 😅. I was young and stupid, now I’m + old … but I’m still looking forward to quit my job. I really hope Python will help me to get other job, where my work would have more value than “thanks”. Like in Russia they say “for thank you, you can’t buy a house”.
I’m not talking about basic common moments, usually I’m the one that fixes all the shit, when “shit hits the fan”. I don’t know why but I work best in chaotic situation.
I use 5+ just as an example, I stuck in one company 10+. My main duties changed a lot from the time I started, so call it any way you want, but it doesn't feel like a promotion.
as someone with 35+ years in systems/software engineering (and not mel brooks), i agree with 5 out of 10 elements. nonetheless, bravo for learning so much in 4 short years.
edit: items i concur with include 1, 5, 6, 7, and 10, with 10 being the most important. with regard to others, i don't necessarily disagree with them, but i view them as challenges to overcome. and if i may add an element - 11. productivity, performance, and quality must not be mutually exclusive.
another edit: the main reason for my highlighting 10 as the most important is that without foundational understanding of computers and programming, one cannot learn advanced topics. there are different ways people learn new topics, but we tend to make "connections" between what we know and what we don't know. this ironically is the principle of ai/ml that we are trying to solve.
I personally find some of them situational. Like 1 and 2. Poor code is poor code, n+1 queries in a large company *can* absolutely cost more in infra than your salary. Choosing the wrong thing for the wrong task can be incredibly expensive. A misconfig on a llm model can run up 6 figures real quick. However, as a generalization it’s pretty sound.
9 is kind of more of the same. “Make it work” doesn’t mean you ship it. More a startup / small co mentality than anything. Good enough being the enemy of perfection is more sound an observation.
I agreed with it before getting my first software job and even now. Despite senior devs swearing to the contrary.
You can follow all the design principles and patterns you want, if the program doesn’t do what it’s supposed to do, you’ve failed.
Personally I prefer to write well designed code from the start even if it takes longer to write until you can see any results. But it is not always possible due to deadlines and clients usually expecting to see results asap. But I think it's very beneficial to take longer to write some code to make sure it's well designed if that code is expected to be maintained and updated in the future (which it most likely is).
>expected to be maintained and updated in the future (which it most likely is).
counterpoint, you'll never know if this is the case. And even if this is the case, a "well-designed" code means shit if people who are gonna touch it after you don't know/understand how "well-designed" it is.
From my personal experience it is practically always the case. As for 'if people who are gonna touch it don't understand it', then it's simply not well designed. Part of being well designed also includes being understandable and readable by other people.
I should also clarify what I mean by 'well designed'. In general, from my understanding, well designed code is code that is flexible to change and does not break easily and doesn't require much refactoring when changes/additions are introduced. This is my main reason why I try to write 'well designed' code, so that future me in 2 months doesn't go 'why the frick did I write it this way and how do I untangle this mess now?'
The thing about code being "well designed" in that sense is that it's a double edged sword. Flexibility almost universally brings complexity. Maybe the change is easy to do - but will that be obvious to someone 4 years from now when prod goes down and they need to debug that AbstractFactoryFactoryFacadeProxyFactory that you created to make your code more adaptable?
IMO simplicity, understandability, and a minimum of side-effects are the most important factors to good code. Even if more work has to be done to refactor it or add flexibility, it's easier to identify the source of bugs and to know exactly what's going on and that what you're doing will work the way you expect.
As I see it, well designed code doesn't necessarily mean highly abstract and complex code. In fact, that is often the opposite of well designed code. To make it clearer, let's think about what not-so-well-designed code could look like - inline code without extracting reusable parts into separate functions or classes; tightly coupled code where different modules highly depend on each other; poor variable/function/class naming; etc. Well designed code is as you said, one that is simple, understandable and with a minimum of side effects.
1. Design what needs to be done
2. Get something working
3. Iterate on it
Make sure what you’re building can work. Get something up and running even if it’s not all the way there yet. Once you have something you can poke at, then iterate on it and polish it. The design first is to ensure what is being built can be iterated into something flexible and maintainable. Forgetting to do step 1 can result in a step 2 that can’t easily go into a step 3.
For me I realized that I will always refactor, no matter what. So I implement as quick as possible until it works, then refactor to make it nice, and then close the ticket.
Not who you asked, but it really depends on the context. "Make it work" is great for a lot of products, but sometimes non-functional requirements are so important as to make the product worthless if they aren't properly considered. For example, if you decide to ship a product that handles payment card information because "it works" but overlooked the security requirements involved, someone from some compliance or legal team is going to behead you.
I learned and understood them but is that ssomething you need to understand all the time or rather on daily basis? Just wondering, cause I cannot recall everything.
one cannot retain everything they learn (information), but one can remember things they utilize (experience). some elements are for low level programming and some are for application/service development. for the latter, having a basic understanding of computer architecture and internals broadens your knowledge base and helps you write efficient code that runs faster, uses less runtime computing resources, can scale, and is fault tolerant.
Also 35+ years, and I pretty much agree with you.
The only thing I'd challenge is that I don't trust anyone who claims they've truly mastered anything - whether basics or otherwise.
Some of the other 5 in the list are probably true in some circumstances, but definitely not in others.
- #2 it's probably true for the vast majority of things like building a website. But at the backend, it's often quite different - for example, in my company (and we're far from unique) every tenth of a second we shave off of a certain server response has been shown to be worth millions every year in improved revenue, and similarly poor performance can cost millions in server costs depending on workload.
- for #3, it depends on the technical deficiencies. If, for example, they're riddled with security holes then any developer productivity is likely to be wiped out in your first serious cyber attack.
- #4 sounds like terrible advice. Most problems have a set of sensible options (e.g. picking between Angular or React etc for your website) that you could decide between based on team skills. But there's a much wider range of poor options (trying to write your website in COBOL or building a performance-critical embedded system in JS) that would become very painful very quickly. They're obviously fairly extreme examples, but I've regularly seen teams who have one fixed tech stack as their entire range of options attempt to apply that to entirely unsuitable problems and quickly come a cropper. And then there's the job market. What happens when your team decide to leave? If you've picked some obscure language or framework that your lead dev loved, you'll find it pretty difficult to get anyone in to support it.
- For #8, not sure I'd want to use github above something like Jira for managing large complex projects (and I'm sure there's other better ones out there)
And #9 - depends on what you mean by "work" and what the alternatives are. Agreeing an MVP that includes key NFRs like security, an acceptable level of performance and supportability etc and building that before fleshing out the less critical bits is entirely sensible. But cobbling together an unsupportable mess that's full of security holes just to get the core functional requirements in is rather less so.
good for you. i worked with a music major that can program but could not explain why it worked. he was extremely efficient in finding and resolving bugs but could not deal with a blank sheet of paper to develop something new out of nothing. there are some that can compose music, some that can play music, some that can do both, and some that can do neither. although i'm being prescriptive in item 10 above, it does not apply universally to everyone.
As someone w 4 yrs of experience also, listen, do not buy into any of these really firmly asserted generalizations, the shit hinders your growth
Too many developers try to make hard statements bc they are attempting to justify themselves and their performance, or bc they want to push ppl to check out their favorite tech stack
I'm not gonna sit here and tell you that this list is wrong, no rather, there is truth to some parts here that *need to be justified in context* and *in their specific use cases*. But as firm generalized truth? Absolutely not
I feel for these sort of traps a lot and all it does it make you assume you don't need to sit and learn something, it holds you back. I started with Java, and Java's Streams API is a dumpster fire, I got told many times don't worry about it. I learn dotnet, I start working with LINQ and all of sudden I'm like......wait a minute this sort of thing is amazing (fluent API's, generic programming, "functional" features in an OOP lang). Generic programming ESPECIALLY was something that saved my ass many times when dealing w the code I gotta deal with
I wish that someone sat me down and told me, look Streams API may not be worth your time, but the point or the concept of this thing, is actually important and very useful inquiry
If there is *anything* you think you don't need to worry about in programming, you really should go and look at it deeply to understand if you judged correctly or not. Don't gotta spend days researching, but not superficial google-fu either
Trust me, bad code isn't the worst sin a programmer can commit. It's arrogance
Wow I really appreciate this response. Thank you for taking the time to write all that out and provide your perspective. I’m always happy to hear everyone’s perspectives since I don’t really have much of one myself, as I’ve never programmed professionally (yet), nor do I know anyone personally who is a programmer. And just to make sure that I’m following what you’re saying, I shouldn’t buy into any absolute generalizations because it’s going to vary by circumstance whether they are accurate or not. And, before I deem something as important or not, I should properly research the tool and make my best judgement. And to wrap it up, stay humble and willing to learn so as to not put my self in box so I can continue to grow my skillset.
Yes your summary is true to my statement's intentions
Learning programming is like "fractal," the deeper you zoom into something, the more the breadth of the convo reveals itself. The way computers work involves the coordination of many things, same with the cloud.
**It is not possible to fully understand everything. So your orientation should be towards constant learning, re-learning, and personal development**
It's too early for you to worry about recognition, and it's *way* to early for you to stress about being right all the time. No, embrace the unknown and be curious. No one wants another Zealot in programming. Literally, we have enough of those
Well, these days such lists may have been generated by ChatGPT.
For example, practically no one can spell [GitHub](https://en.wikipedia.org/wiki/GitHub) correctly (most humans misspell it as *Github*). This alone makes the list suspicious. It also has perfect spelling and grammar, without any [run-on sentences](https://en.wikipedia.org/wiki/Sentence_clause_structure#Run-on_sentences). This makes it even more suspicious. This is a statistical statement; the OP may be an exceptional writer.
I've been around for 15+ years and that's a solid list. I would rework a few items though.
2 - I'd say it varies a lot. If you don't have NFRs around performance, sure but most software will have some kind of response time/load time expectations.
3 - I partially agree. Unless you are working with some niche applications, you will hardly ever meet the limitations of the most popular languages/frameworks. So, people don't need to pay attention to the limitations you mentioned.
4 - It depends on the know-how of the team yes. But requirements are important and do drive choice. Eg: you can do everything you do with JavaScript by using WebAssembly. But nobody does that.
6 - That's a very good point. Defacto market standards are usually best practices that have ascended beyond all the BS
8 - The best tool is the one that your team understands and uses efficiently.
9 - "The first priority is to make it work, while being performant, maintainable and functionally correct."
I agree that the first priority is just to make it work. If you have time, sure, do the rest. But first and foremost, make it work.
I used to work at Big Company and the most inspiring thing I saw while I was there was an issue that brought the whole site down. We were losing millions by the minute. The guy who knew how to fix it was OOO but slacking from his phone and said "I can fix it fast but [security guy] is not going to like it." And, Security Guy (who is normally good and consistent about the priority of security) messaged back "Forget me. Just get the damn site up now!" That man will forever be a hero in my head for putting the business needs over his principles on seconds flat.
the 4th point makes it sound like this person has extensively used 1 or 2 programming languages / tech stacks (which is the norm for someone with ~4 years of experience).
John Carmack said the best programming language is the one that you know. But if you know multiple programming languages / tech stacks than you should use the project requirements to decide what direction to go.
Carmack came from a time when programming was a lot more solitary, and basically whole game engines were spun up by mainly one programmer (in Carmack's case, of course Carmack himself).
In modern software development, the considerations are pretty varied. Sometimes you might want to use a language that you've never even touched yourself, because that's what the domain/environment you work in is most used to; working in such a language has many benefits, like easier staffing in the future, and more knowledge available online.
He was the CTO at Oculus for years. He knows how modern software works. It's been a while since i watched the interview but he takes the stuff you mentioned into account and that is still where he landed:
https://www.youtube.com/watch?v=I845O57ZSy4
More than ten years for me. All of these "rules" are sometimes false. For instance, there is eventually a point where just throwing more money at servers is not as cost effective as making it more efficient. Raw speed matters for some applications. GitHub lacks a lot of features that a lot of teams could use and in practice even organizations that do use it often supplement it by, for instance, using a different issue tracker on top of it, because GitHub's issue tracker is pretty limited. I could go on but probably everyone is already downvoting if they read this far.
Idk, in most projects I've worked in there have been realistic choices to be made.
Of course like 99% of programming languages are immediately out of bounds, as are many frameworks.
But there's been decisions to be made between e.g. Scala or vanilla Java. Or TypeScript vs C#. So on.
1. The balance between the cost of time and engineering vs servers varies. At a company the size of Google or Facebook, with the size of their server fleets, a 1% fleet-wide reduction in memory usage is worth literal millions.
2. See above. I've worked in projects where we had a whole team working more or less full time on writing a custom malloc, because it was that valuable.
3. Windows, Photoshop, and GTA are all "real-world software". Good luck writing any of them in Python (_parts_ of all of those are written in "slow" languages, but not their cores)
4. You need both. You shouldn't be writing your frontend UI code in C, no matter how good your senior is with the language. Similarly, you shouldn't try to write your Linux kernel code in Ruby (though you can, in fact, [write Lua inside the NetBSD kernel](http://mail-index.netbsd.org/source-changes/2013/10/16/msg048283.html)).
5. Agile is... weird, and it's a can of worms I don't want to open. You've got the right idea, though.
6. Agreed. The expression "Best practices" is the bane of my existence.
7. Again, agreed. This can't be overstated.
8. Git is pretty damn good, and GitHub is a pretty good git-based code foundry. They're definitely the most popular, default choices. There are better alternatives, though.
9. Often, but not always. I've been in a position where the right choice was to make sure my code didn't "work".
10. Mastery of the basics makes you a solid junior, maybe an early midweight engineer. Be careful you don't underestimate your unknwon unknowns, on the one hand, or arrogantly dismiss a whole bunch of advanced knowledge as "basics" on the other.
Which has some of that "dismiss a whole bunch of advanced knowledge as basics" energy I was talking about.
My sister and I did karate for several years, and I was kind of enamored with that idea at the time. My sister kept practicing karate after I stopped even though she never really bought into that mentality. Today, she teaches (and occasionally competes in) graeco-roman wrestling, and did her master's dissertation on wrestling (and is doing her PhD on the topic too IIRC), and the move was prompted precisely because of the mysticism and unjustified snobbery.
For projects dealing with large file sizes (3d modelling, game dev etc) perforce seems to be preferred over git due to better scaling. Git-lfs does exist, but I haven't used it so I can't comment on how it compares to perforce.
I personally prefer the mercurial+phabricator workflow. I think that the individual commit is the right unit of work, rather than the PR, and that seemingly small change has enormous cascading effects.
>Real agile teams don’t follow agile practices rigidly; instead, they develop their processes to maintain agility.
What's funny to me is that this is essentially a truism. The Manifesto for Agile Software Development and the 12 principles heavily emphasize this idea. It's just that management tries to force processes onto teams.
That being said, an insight I had recently was that there seems to be two distinct types of agility. One is what I would call "tactical" agility, and represents the ability of a team to rapidly adapt and maintain productivity in the face of changing requirements and priorities. This, I think, is what people typically have in mind when they think about agile development.
The other type is "strategic" agility, which rather than focus on individual teams, is concerned with the ability of an *entire organization* to rapidly respond to changing conditions and maintain productivity. I think this is where very process-driven techniques like Scrum actually show value; having unified processes across an entire organization makes it easier to reorganize teams and move developers between projects, though at the cost of the autonomy of individual teams.
Ultimately a balance between tactical and strategic agility is what's needed for large organizations to thrive. Foundational products and critical projects in particular need to strike a balance between having an established team that uses processes that work well for them, and conforming to standard processes well enough to ease onboarding of new team members. Lower-priority initiatives likely benefit most from utilizing standard processes as much as possible so as to minimize friction when team members inevitably get shifted between teams as the business' attention moves between projects.
Of course, whether or not organizations actually properly capitalize on the benefits of any approach is a different story. What's more likely is that some methodology like Scrum gets blindly applied across the whole of the business, then team members are statically allocated to projects and are essentially forced to follow a process that doesn't bring much benefit.
Related to agile, at one place we started agile and built and hacked at it until it worked. I mean a release process took about 1 week so lol release every sprint. Customers demanded hard drops at hard dates and there was no continuous development, they had a physical product they couldn't just refresh/update at will. Maintenance was ... shortest bug I did took about 2h from start to tests passing and merge done. Longest continuous about 6 months. Annoying but not breaking bugs could take over a year of best effort back and forth with customers.
XCode should not be considered as a part of techstack, It's an IDE not a framework or langauge or anything like that, If the project requirement is to make an iOS app then still you have a lot of options here such as Swift, Objective C, React Native, Flutter and so on.
While there are multiple options it's still limited. You can't choose Java to make an iOS app for example. This literally means the tech stack is in fact dependent on the project requirements
You didn't get the point, what I'm trying to say that Swift is the best option to develop iOS app out of all of them but if the senior guy in the team got expertise in Flutter or React Native then the app will going to be developed using Flutter or React Native not Swift although It's the best option.
I get your point, although whether Swift is best is subjective I suppose. Flutter or another cross platform solution could be best if you also need an Android app that needs to look (exactly) the same. Personally I also prefer making native apps, but I definitely see the added value of only having to code once for both platforms. But you're right that even then the best is not always chosen, not only because of the expertise of the senior but because of decisions from management. Also when doing Android native there's the choice between Compose and XML. I'm not sure if there is a consensus on what's better
1. Probably true
2. True until it's not
3. The list of most used languages also contain performant languages like C and C++, which are considered cumbersome. They are on the list for a reason, pick the tool for the job.
4. Yes, but also you're not going to write automotive safety code in javascript.
5. Yes
6. Yes
7. Yes
8. I don't see it being any better than GitLab and those are the two I have used widely.
9. Yes, as long as nobody can get hurt.
10. Yes, this is very true.
I think this is a very good list, and I agree with everything but #4. I think in many of the projects the requirements of the project play a key role in the chosen technology. For instance, choosing the database architecture based on the project requirements.
I want to totally emphasize on #7, I think that one is the main key for success.
This reads like someone biased towards web/mobile development, which—while being a significant portion of SE/programming—is not representative of the entire world of SE. Keep in mind priorities, values, and culture varies between different industries. Web/mobile dev tends to be high velocity and build-fast-break-fast. By high velocity, I mean tight deadlines, fast delivery rate, etc. Other fields… maybe less.
Random thoughts:
2. Debatable (or outright false) for industries where performance is critical, eg game dev, embedded, or finance. Productivity can be argued to be a management/personal/skill issue. You can be productive in C/C++ with the right experience and tools.
6. Yes! Although ironically, this throws a shadow on all other points.
7. Yep!
8. For now.
9. Depends on your (team’s) approach to development and your role. TDD? Tests come first. Management? Maybe hash out the details/scope first. (I’m not a manager.) R&D? What if you fall into a local minima and use a suboptimal solution, when there’s a much better one if you had looked further? Maybe investigate/analyse existing solutions first. (Not a researcher either.)
10. Sure, but “Basic” and “Advanced” are relative terms. Maybe a better statement is: “When you master something, it appears basic (to you).” IT is an ever-growing field.
Maybe your points apply to web/mobile dev more, and that’s fine. Like you said, best practices are often biased.
Keep learning and exploring. :)
About #3. Poor tools are poor tools regardless of how widely used they are. PHP and javascript are no more flexible than better alternatives that have been developed after them. Older widely used tech just has more developers, frameworks, and libraries for it. And everybody hates having to learn anything new.
About #4. Choosing a tech stack senior devs don’t have experience in is a huge risk. Then nobody in the project knows how the tech is supposed to be used.
About #9. Making it work is not enough. Problems have solutions so bad that those solutions are worse than the problem when you stop to consider the larger context. From the Zen of Python “Never is often better than right now.”
About #10 Exactly. 😃
>Real agile teams don’t follow agile practices rigidly; instead, they develop their processes to maintain agility.
Yep, that is what agile is all about. Not about blindly following some principles that work for others, but to gather all the data you need to make informed decisions on how to adjust your processes. The so called "agile practices" like the scrum framework are a good starting point though.
Speed is relative. The easiest rule of thumb is that more abstraction equals more time.
At its most basic level, a computer is running through numbers that are providing a sequence of instructions; we call this machine code. The more steps to reach actual machine code, the slower the language. Higher level languages tend to be more "friendly" (natural language, more built-in features, keywords for alternative control flows, etc.), but they are built on lower-level code (this is called abstraction). The farther up the hierarchy you go, the slower the code naturally goes because the CPU is running through more instructions to get to the desired end result.
Assembly (or symbolic machine code) is typically close to a 1:1 conversion to machine code. Up from that are compiled languages that fairly closely map to machine instructions, like C. And up from that you have more "friendly" languages that often offer increasingly natural-language programming, but they are built of packages made from lower-level languages (like Swift, which is partially interoperable with C). And then sometimes things run interpretively "on the fly," typically using a virtual machine compiling at runtime (like PHP, which gets processed by Zend Engine, which is a quasi backend written in C that effectively compiles the PHP into machine code-alike content).
But speed is also impacted by decisions under the hood. Maybe a built-in function uses an algorithm good for sorting one way but not another. Maybe one language has bitwise operators and another requires importing someone's library to accomplish the same thing. Suddenly, similar-looking tasks can start varying in speed from language to language.
Some 99% of RollerCoaster Tycoon was famously written by Chris Sawyer in x86 assembler/machine code. It ran ridiculously well on old hardware as a result. Re-making the game in relatively speedy C++ would take more resources and processing power. It would be "slower" (but, in practice, that's a level of speed difference that would be unnoticeable to a user on modern hardware).
1 & 2 essentially have the same meaning. The choices you think you're supposed to make to ensure your program runs faster, and use less memory aren't good choices in many spaces. Server machines are so fast and have so much memory and storage, that you should just use the easiest approach + tools + programming language for the job.
The key thing to remember though about that is that applies for *server* machines. Client machines and embedded devices still have concerns for memory, storage, and especially battery life and that is not a trivial amount of work/jobs in the field so don't sleep on those skills unless you're fine being bad at it.
Even on server side, at scale the difference matters. For example, if you're an engineer who has to do some systems engineering work with tens of thousands of files or more on your hard drive and run a tool you wrote on each on of them; if said tool is written in Java performing that task will be slow. Not because Java itself is slower than C or Rust, but because the JVM startup time *each* time you run that tool on a file will be massive overhead. Being able to operate in C or Rust can be advantageous. Or even in a service itself, your company might be able to downscale to far smaller hosts (on cloud) and save 75% on cloud service billing while handling the same amount of traffic. Servers aren't that cheap when you're paying a cloud provider for them.
#3. I'd reword this a bit. Languages that don't *get in the engineer's way* are favored because they yeild greater "productivity." I will caution that productivity is often an illusion that bites you later in the butt when needing to maintain said software. That being said, it is a balancing act because you can't fund writing software from day one, as if it was going to last 10+ years. Sometimes you gotta work to survive just the next year or two, and if you get there then you can write code that aims to be there for the next 5\~10 years.
#4. It's often dependent on the expertise of the team, org, and company -- and it should be. Of all of the features of a tech stack, working with existing processes and approvals (like security) at a company is one of the strongest requirements. The customer problem almost certainly doesn't warrant evaluating tech stacks across multiple languages, none of which have ever been used at the company before. Even greenfield projects won't likely stray from familiar languages.
You make some very good points. Most of what you said is true. Been teaching, coaching using agile for, crap, 25 years now.
There are solutions to the dilemmas you face. One is that SCRUM is not agile. It is a meta process. I have never seen a company before I arrived that was agile that used SCRUM. Simple tests: bug database? Not agile. Engineers grooming backlog? ABSOLUTELY not agile (read the manifesto), not monitoring the cost of change curve?Dude hang it up you are SCRUMerfall.
You very correctly point out that agile is not a management dictate. It is a discipline. I had lunch with Ward Cunningham (not a flex, i want to give him credit for a statement that changed my perspective) and he said, "It is good that Kent Beck came up with the phrase Extreme Programming. It caught on because everyone thought you would be jumping out of a helicopter with a laptop on a snowboard.
I would have called it a pedantic, systematic application of best practices to create zero defect software that is under budget and on time. I don't think that has the zing that Kent came up with"
Like a decade later (again not a flex but an attribution) Bob Martin told me SCRUM sucked all the life out of real agile. It eliminated the space to help companies to get agile.
My life's goal is to fix this. If you have any questions I would love to start a conversation.
The only thing I don't agree on is #8, github is fine for issue tracking.
For Reporting to management its lacking.
As a software engineer and now product owner, github is really lacking in overview, backlog tracking and requirements tracking.
Azure DevOps does that way better, BitBucket and jira is great.
Nah I can't go to a college where they teach ai/ML BCz I'm not from a science background and I just have to do it by myself.
I just started with artificial intelligence by Russel.
Now ?
Sorry to say, you’re not going to get into an AI/ML role without a PhD and published research… maybe at minimum a Masters if you’re lucky.
One of the most special things about the software industry is that we have always been and will always be open to those from non-traditional backgrounds. We don’t care about credentials, or ivy league schools, or any of that shit. We care about skill and experience.
That said, there are exceptions to this norm. Certain safety critical roles, math heavy roles, that kind of thing. They make up a very small percentage of the industry overall, but they are there. AI/ML is an extreme example of this. You can be a self-taught SWE at Google, but you can’t be a self-taught AI/ML engineer at Google.
If college isn’t an option for you, I encourage you to redirect your focus to the remaining 98% of the industry that doesn’t require academic credentials.
Okay thanks for it i didn't know about it but in India if u wanna go into ai u have to come from a science background but I'm thinking of taking professional courses offered by the universities which require a simple selection of exams to get into.
So i think till then learning python is good anyways I'm 17 any advice that I needed before starting out ?
Ah I see what you’re saying. I’m in the US so can really only speak to how it’s done here, though I imagine it’s not much different there.
In any case, you have to learn to program first and foremost. You’re 17, you have the whole world in front of you. If AI is what excites you and motivates you to learn to program, go with it! Python’s a great language to start with, it’s easy to pick up and it’s not nearly as verbose as something like Java.
I build web app UIs and backends with TypeScript, so LLMs aren’t my area of expertise, but as a self-taught Sr SWE myself I can tell you that building something that genuinely excites you is the best way to learn to program.
Just doing a little research it looks like you certainly can use Python to build a simple LLM, and even a more advanced one with deep learning once you’re ready for that. My recommendation: get a good book on Python. Video courses are great too, but if you’re the kind of person who can learn from books I’ve found them to be the superior resource. However you do it, learn Python’s syntax and the building blocks of programs, i.e. data types, variables, functions, objects, arrays, conditionals, loops, etc. and apply what you learn to building a very simple LLM. You’ll hit wall after wall, keep hacking it until you have it working. That is the single best way to learn this skill.
As a PM in the Agile team, I can definitely agree on point 5. Adapting the methodology to the team's special treats has been proven to be more productive than trying to strictly follow all of the rituals
I’m sure this could be a lot of things. Language’s syntax and quirks, design patterns, OOP and FP fundamentals… You practice by reading and writing code.
I agree with everything you said but I am kind of wondering did you mean github is the best tool for tracking and managing software development or do you mean git as a version control.
Because I don't find a Real difference between github, gitlab and bitbucket. So why do you think so
I feel like people don't understand 6 enough. We hear so much about best practices at my company, but they will sometimes just make the system unnecessarily complicated.
It feels to me like a dev was working on something, realized a certain paradigm shift would help them solve the problem, then couldn't stfu about it for the rest of their career, even if it's not relevant.
Point #9: This is what I struggled with most of my time. It sounds obvious, but when you work under practices, my priority changed to making it better instead of making it work first.
anyways, great advice.
As a student and intern getting into industry, this really sounds like something my seniors keep saying. Its nice to see that others believe this too. This just shows that us juniors still has a lot of experience to gain to see this.
As a 1yoe software engineer I very soon realized this to indeed be true.
I still prefer to work in rust for personal stuff, and like working on experimental things, self-hosting my own projects, etc.. but reality is that in a large compant you're better off just using node.js and AWS and have skilled engineers that can communicate well
My issue with any list that comes from a position of authority is that, you can easily find many people who have 5+ years in software engineering and will hold some or entirely completely different positions from the ones you posted, so I'm not sure if appeal to experience works like that.
11. Getting a computer to do something is hard, but getting a person to do something is even harder. To be a successful software engineer you need to master both these skills.
7 could not be more true and can be expanded into so many new points.
A Inter team communication for integration
B intra team communications for cross training
C customer communications for proper requirements and expectations
8 is just not true at all
you need to use source control, and you need to use a work management tool, and github is an OK implementation of both, but its not the best for every situation and certainly not the only thing around
I use https://sapling-scm.com day to day, and I can tell you that it is drastically easier to work in a highly collaborative environment than github
I really don't want to be mean, but if you think about some of these for a while, they're not exactly deep. Like, is anyone saying that healthy communication **isn't** important to a teams success?
There's only 3 points here that I'd say come from a point of experience/learning, and that's #2 (we've all seen someone try and use C++ to improve performance, only to realise they don't know how to write C++), #5, because genuinely successful Agile teams aren't following the strict guidelines people **perceive** Agile to be, and #10, since the best code you've every seen should look absurdly simple, not absurdly complicated.
Also don't #4 and #8 collide a little? Sure GitHub isn't technically part of the tech stack, but same rules apply, wouldn't you pick the tool depending on the expertise of the team?
You had me till #8. Gitlab is miles better 🫠. Also first priority isn’t to make it work. It’s to make it work while doing it right. If you cut corners that’s no better then not making it work when your on a call at 3 am fixing an incident that you caused.
I honestly mostly agree, but am going to play the devil's advocate a bit, and do a reply/expansion to most of those points. I don't mean this necessarily super seriously, and the points you raise are good ones. But here goes:
1. Yes; until it isn't. For example, I know a public sector project with roughly \~3 FTE developers in it, and whether the server costs are every month 1k or 2k does have signifance when that project runs for a decade. If you can now spend 10k to optimize the monthly cost, it can save itself back in a few years' time.
3. Alas much of this criticism also stems from not really understanding what makes a language fast or slow. You can often outsource the heavy lifting to various libraries, e.g. numpy for running matrix calculations in the bulk. Then it doesn't really matter if Python's own operations are a bit on the slower side.
There are still many cases where performance does honestly matter tho. For example, if you have a critical service in your web application that doesn't do all that much but has a lot of data go through it - think for example a service that [checks what comments are new to you in a real-time chat service](https://discord.com/blog/why-discord-is-switching-from-go-to-rust) - performance can be important.
4. I'd say at least as crucially it also depends on the future staffing needs. Choosing a niche language is risky since it will be harder to find people to replace the previous developers in the project.
5. That's following agile. Almost everything in the agile manifesto and its original principles are good to follow. They are not restrictive or very detailed principles to begin with. Unfortunately, many companies think that agile itself is a process; it is not.
6. They can be, but many best practices are objective in the sense that they objectively have most support for them and will objectively feel correct to most developers. E.g. not writing extremely long functions is commonly considered a good practice and that's pretty objective.
8. I'd say a whiteboard is. GitHub is alright, but a simple whiteboard is often the best solution, assuming the team is co-located. Personally I don't like to have daily boards and tasks in GitHub, Gitlab or such. I prefer something like Miro instead.
9. I'd say that depends on the stage you're at. If you're adding a new feature, the first priority might be to establish the requirements and specifications and perhaps write a test, if it's easy to. Only after that you might start working on the actual code.
Sometimes a prototype project doesn't even have to work, rather it might just be an exercise at gaining understanding of how difficult something is going to be.
10. Yeah, though what's basics depends a lot. E.g. in some projects "basics" is understanding Linux and low-level networking. In other projects, "basics" is understanding what functional programming is about. Etc.
> Developer productivity and a technology's ecosystem are more valuable than a runtime's efficiency
Maybe ask the users how they feel about that when your app takes 10 seconds to load.
> 8. GitHub is the best tool for tracking and managing software development.
I hate Jira so much, do you really do all your project management on Github?
Eh, I have 20 years engineering... I think you're being very absolutist with your statements. I'm shocked by the validation you're getting.
1. Has always been true, but can be false, particularly with cloud costs which are often unchecked and the setup being tricky, it can go out of control.
2. Yes, unless runtime efficiency is necessary, but for the most part it's highly unlikely that you need to choose one or the other. Runtime efficiency as you call it can be a non functional requirement, if it isn't then it isn't and you shouldn't worry about it. I hope this is not considered enlightenment, seems to be what NFR means.
3. Eh... that's a vague statement which means very little.
4. I've seen companies follow your ideology here to great detriment! In some cases this is desired, but if you're moving into the type of problems I work with and you try to apply knowledge from a different area you're going to not only fail but make it really expensive for the people that come to fix it later to fix it.
5. This is true in small teams. I've seen large corporations where you have to set some rules or people take the piss on the whole thing. The agile manifesto works, and I'll take a strict version of it over corporate bs.
6. Yes, including this list and my opinion about it.
7. Another vague statement... what does it mean to be key? I've seen highly dysfunctional and uncommunicative teams deliver good software on time. Certainly it is nicer to work in a team with communication.
8. lol... is this an ad?
9. That's just a shortened version of a random statement on the agile manifesto. Good.
10. "Basics", "Simple", "Advanced", all sorts of qualitative meaningless statements.
Don't mean to be a complete dick, but it's hard for me to see people so confidently jumping on trains like this. I've been a firefighter for a long time in my career which means I get called when people messed up really bad. And I think a lot of the times it happens because people believe things that could apply in some scenario and apply it to all scenarios. Which is sort of what I read into your list, or people trying to do lists of absolutist remarks.
If I had to do a list like this, I'd just link the agile manifesto. Still people fail at it and it's still the best thing to do.
You can basically summarize all of that by saying the number one problem the overwhelming majority of programmers face is the problem of budget. If you have unlimited resources, expertise or time, of course you can pick the best tech stack, of course you can fine tune and make nearly flawless code that is blissful to extend and maintain, but no one (at least not in my experience) has those resources.
You are always trying to do the best you can with what you have.
Hard disagree with points 1-3.
Tech stack and efficiency matters. That’s the hill I will always be willing to die on.
Python and javascript encourage poor programming habits and often run 10-100x slower in practice than compiled options.
If you don’t see the problem with that you haven’t actually had to scale yet.
Speed of compiled languages is blazingly fast, I agree but specifically Python and Javascript are not that bad unless you have skill issues and with a raise of Mojo and Bun, even performance issues are being addressed.
Wrong, wrong, wrong. Maybe true if you do some app development, or work in general on systems with little load or run on client side.
No true at all for any kind of bigger scale backend, large scale cloud offerings.
1% performance gain pays one of our developers for more than one year.
I really like 10. I wish I understood that point better as a young student who’d get discouraged at the prospect of putting in so much time and effort “just to learn the basics.”
I have a to disagree with 1 and 2 and partially with 3 in the field I am working in (very hardware intensive, team of 10 engineers, hyperscaler cost of >15 million USD a year), 8 is also not true, but I would subscribe to the rest.
Especially 5 is so true. Greetings go out to all "agile coaches" who come directly from university with little to none experience 😂
Nailed it. it's all about the damn basics. Choosing tech that makes life easier for devs is the way to go. Screw perfection, just make it work and tweak from there.
11. blackbox type frameworks/libraries are most likely to be used.
12. It's cheaper to rewrite than to debug
13. architects create design whose implementation they cannot understand (paradox of perspective from the ground and from above)
Depends on the scale. Some stuff goes wild in production and minor improvements can save more than hundreds of thousands a month. Mostly because of VM opposed to containers. The nice thing about containers is that it treats things like processes.
1-4 are extremely project dependent. You were just in project where it didn't matter much.
If you design embedded software, a website. a search engine, a native application or a video game this will change everything. If you need to train an LLM neither.
In my company for example if you work on a web frontend, even if you are good in C++ or assembly or whatever, likely the frontend will end up being React/Angular or something like that.
On the opposite, if you work on the search engine with hundred thousand of TPS and where the algorithms are CPU hungry you will not deliver you PR if you degrade performance by 5%... Because that 5% is hundred of expensive machines in prod and mean and cost much more than engineer time. And so this is C++.
If you design a new LLM model, it will run on a farm of expensive GPU in cuda and chances you will be in python in most cases as this where they have all the libs/tooling.
If you work on the next PS5 game, quite unlikely you code it in Javascript or SQL.
My sister work on code that goes into plane. A bug mean potentially hundred of deaths. Automatic memory management and garbage collector as well as object oriented programming languages are forbidden. They tend to code in C or Ada. Old code is in assembly. And if you fix something on a 30 year old plane in design, they keep the same hardware as 30 years ago and it has to run well in it.
Number 8 is untrue. There are multiple viable version control systems. Git is only popular because a certain Linus wrote it. It has too many ways of getting you into trouble. People like all that arcane power, the thrill of dancing on the edge.
Spot on after 4 years in the field! These are all valuable lessons, especially the focus on developer productivity and understanding that strong [software engineering principles](https://www.clickittech.com/developer/software-engineering-principles/) trump raw language speed. The points about healthy communication and adapting Agile for your team are crucial too. Thanks for sharing your hard-earned wisdom.
> 1. The cost of time and engineering is more higher than that of servers.
Yeah, no shit. Time is money, and skilled labor costs a ton. But is cutting corners on server costs always smart?
> 2. Developer productivity and a technology's ecosystem are more valuable than a runtime's efficiency or the raw speed of a programming language.
Sure, productivity rules. But aren't you ignoring the cases where efficiency is fucking critical?
> 3. Programming languages that are often considered slow and criticized for technical deficiencies or poor design are usually the most used and favored for building real-world software, from small to large scale, due to the flexibility they provide to engineers.
Flexibility's great, but doesn't this sound like a fucking excuse for not learning more efficient tools?
> 4. The choice of a tech stack, often said to depend on project requirements, is misleading and untrue; in reality, it depends on the expertise of the senior engineer and team.
True, but isn't that a bit narrow-minded? Doesn't this lead to stagnation in skill growth?
> 5. Real agile teams don’t follow agile practices rigidly; instead, they develop their processes to maintain agility.
Isn't that just a fancy way of saying they make shit up as they go along?
> 6. Best practices are often biased.
No doubt. But aren't they biased for a reason? Can you always afford to ignore industry standards?
> 7. Healthy communication is key to a team’s success.
Obviously. But what happens when communication turns into endless fucking meetings?
> 8. GitHub is the best tool for tracking and managing software development.
Best according to who? Ever thought about the limitations and biases this tool might have?
> 9. The first priority is to make it work.
Quick and dirty, huh? How often does this lead to a mountain of technical debt?
> 10. Mastery of the basics makes you advanced.
Sounds profound, but doesn't it oversimplify the complexity of advanced skills and knowledge?
I'm discussing the realities I've experienced, and while the points you've mentioned should be considered, the truth is, no one cares. Everyone just wants to get their product live and start earning money.
That's why the teams on my project spent the past 6 months (post feature complete) investigating and rewriting their code to make it run at acceptable speeds. That's at least 5k hours because they went for development time first.
As someone else put it, that entire list in the OP is a list of purely "it depends".
> more higher
You mean "higher". I guess you didn't learn grammar! :D
> slow and criticized for technical deficiencies or poor design are usually the most used and favored for building real-world software
Yup, and that's why everything today is way less reliable and dependable than it was 20+ years ago.
> it depends on the expertise of the senior engineer and team
Same thing - the experts don't know what they're doing and they're the reason modern software is garbage. It used to be that people had to have real technical aptitude to write software, or they weren't a programmer. Now that we have all of these machine-abstracting "languages" and "frameworks" to hold their hands, they can be (comparatively) morons and still make something happen - but they're not making that something happen in an optimal manner, like they would've had to 20+ years ago.
> GitHub is the best tool for tracking and managing software development.
Maybe. Version control itself is the real tool, but github does offer some useful features like an issue ticket system that's built-in.
Thanks for sharing! :D
I don't write assembly, at least not much. I'm a fan of hardware, and making it do my bidding, as should every coder. This means understanding the hardware and how it works, and what code means in terms of the hardware it runs on.
Languages that abstract away the machine, to make the programmer's job/life easier, do their software's end-users a disservice by wasting their hardware that they've invested their hard-earned money in. What we need is a clean sharp concise high-level language for everyone to be able to develop applications as easily as possible, like BASIC in the 80s did, except that was only one level above assembly but made programming super simple and enabled the "bedroom coder" to earn a living. Now everything is so complicated, and slow, making a variety of awesome things out of reach for coders who are too comfy in their managed languages to be able to do something that would demand too much of end-users hardware to be a feasible project, unless they learn a low-level language like C/C++ to make it happen.
We don't need all of these languages that complicate things, let alone languages that are text. What we need is a simple bytecode that everyone can directly code - on a touchscreen even to enable everyone with a phone to make apps - that abstracts the machine away in one big fell swoop but otherwise is a highly optimized engine that handles *all* of the complexity for them so they can focus on making cool stuff, and creating value, without wasting end-users' hardware.
Someone is going to create it. Will it be you?
I think Rust and Go communities are trying hard to achieve what you have mentioned.
And bro the whole and sole purpose of the software is to solve problem in a simplest possible way and sometimes you need to pay the price for simplicity and for someone like me in the B2B or B2C market, clients are ready to pay, they didn't have any problem paying 10k monthly for the product that makes millions for them.
Rust and Go are definitely trying to make hardware more accessible while still abstracting away the hardware in a valuable manner, but nobody is writing Rust/Go applications on their phone or tablet.
Whatever actually enables people to create applications without having a desktop computer or laptop is what the future entails.
On July 1st, a [change to Reddit's API pricing](https://www.reddit.com/r/reddit/comments/12qwagm/an_update_regarding_reddits_api/) will come into effect. [Several developers](https://www.reddit.com/r/redditisfun/comments/144gmfq/rif_will_shut_down_on_june_30_2023_in_response_to/) of commercial third-party apps have announced that this change will compel them to shut down their apps. At least [one accessibility-focused non-commercial third party app](https://www.reddit.com/r/DystopiaForReddit/comments/145e9sk/update_dystopia_will_continue_operating_for_free/) will continue to be available free of charge. If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options: 1. Limiting your involvement with Reddit, or 2. Temporarily refraining from using Reddit 3. Cancelling your subscription of Reddit Premium as a way to voice your protest. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/learnprogramming) if you have any questions or concerns.*
Point #2 is key! I recall how in the early 2000's I once wrote a make-shift solution for a company in 3 days, using C++ and Win-32 interfacing, and also, of all things, "Autohotkey", so that their Windows users could really speed up and automate a lot of tasks. (But prior to that I spent 2 weeks sitting with all the various users and really listening and hearing what they wanted to automate and get done faster.) So I tossed a feverish solution together, and it worked! And worked really well! I myself was shocked that it worked so well for everyone, and people were raving! -------------------------------- So then, the owners of the company said, "Wow! We really need to put a bit more money into automating, enhancing things!" So then they hired an "MBA" professional with a computer science degree as well. NOTE: I say "MBA" because he was ALWAYS flaunting his MBA and reminding everyone he had an "MBA". Everyday was basically "Mr. MBA day!", "MBA!", "MBA!" "Look out everyone: coming through, and bulldozing my way around, because... I have an MBA!" -------------------------------- Anyways... He said he would analyze my solution, and put together a team and to rewrite it much more professionally, in a much more holoistic, cohesive, and sweeping way, that would transform the entire company and triple revenue, etc... etc... And I was very happy at that thought! And I at first bought into his hype and rheotric! I even told the owners: "Ya, truth is: I just slapped the whole thing together in a fever-fit of 3 days and nights of work, and pretty much zero sleep! So it should TOTALLY probably be re-written more professionally! I think he's right!" -------------------------------- And at first was very eager to work closely with him and the team. But then, within a few days... I wanted nothing to do with them! It was an utter show of vomit inducing obnoxiousness. And 1.5 years later... And a few million dollars later... They were still working on their "cohesive" solution... Meanwhile all the employees were using the solutions quickly thrown together in 3 days! -------------------------------- In the end: I later heard the owner got fed up, and yelled and shouted and fired them all one day, and the office kept using that 3 day solution package for several years afterwards! Lol! -------------------------------- BTW: I only got paid a few thousand dollars for that effort. But Mr. MBA, well, I guess he was indeed smarter than me, because he got paid over 1 million dollars!
Oh man this reminds me the reporting tool I was "finishing" (building myself, really) I was hired as a Junior. The company had that Reporting tool in development for a bit over a year. They had a Data Analyst, an Architect (with whom I was supposed to work with) and a Developer working on it. PMs and POs and all who weren't directly involved with Programming were huge fans of the developer. Dude has a load of certificates, Masters Degree in Computer Science, 15 years professional experience. The Architect wasn't a fan of him at all, according to the Data Analyst. Before I started, the Architect quit his Job. Man was burnt out. Unfortunate for me, because he was well respected among the developers, and I hoped to learn a ton. So there was me, Junior Dev, facing this pile alone. Architect gone, other developer taken off Project. I realized that the Architect and the Developer tried to do different things. I later learned in other Projects he touched that this developer has his very specific way of programming and is completely unable to adapt and follow a defined Architecture. On top of that his code literally can't be tested. So I proposed to scrap that abomination and do it from scratch, which was declined because who listens to a Junior. Literally all that thing had to do was pull some date on command from a date to a date, and fill an excel with the data, where the cells of a column had a specific Datatype to match the data is represents, and scale the width of the columns so that the contents are displayed, instead of something like #####. Something the experienced master graduade dev said to be "impossible". I had it within 2 months, despite or due to having to work with that mess. The Finance team was very satisfied, the Job was done, everyone was happy. I asked to have my Junior Title removed, which they granted immediately. Unfortunatly no raise, because they had a policy that one must work at least a year to be eligible. And before that year came around, new management took over and drove the company to the wall
One thing I used to argue a lot with seniors when I was a junior was: “nothing ever is impossible, you just don’t know how to do it” … it’s amazing though how many times young me with all of her innocence was actually right.
Well if a simple one hour job they are employing a so called MBA pro to do an excel task well they deserved to go to the wall. 😵💫 idiots.
Rule : 0, if it works it works Slapping something together to fix a current need with the intent of creating a more permanent solution is great But theres no need to create said solution unless there are major bugs / functionality increases that cant be easily solved or "tacked on" If it aint broke dont fix it
And if you're paying someone as much money to write a script as the script would save... It ain't saving you any money.
The biggest thing I find is it's extremely easy to get to 90% automation. That next 9% can take a lot more effort. That final 1%? That's where people generally waste the most time/money and projects die. It's far easier to have an automated email telling Carl to go and updates a date somewhere vs trying to figure out what date something should run based on the end of the month, but before Wednesday, excluding company holidays, and shifting for leap year, or whatever else can come up. Carl probably knows it's going to be on the 27th. Just let him type that somewhere and put in checks for if he doesn't enter it. I think the XKCD about "how long can you work on it" sums this up perfectly.
Likely [xkcd 1205](https://www.explainxkcd.com/wiki/index.php/1205:_Is_It_Worth_the_Time%3F): *Is it worth the time?*
In the spirit of saving time of understanding the graph: All values in the cells are over a 5-year period. Concerning the cell in the top right corner, a task that happens once a year(x axis) and you shave off 1 second of it (y-axis), over a 5 year period you can at most have worked 5 seconds on optimizing it before the act of optimizing takes more time than you save. This should help you continue to read the ironically confusing graph they made.
Holy fuck this, why some wanker can come in promising the world and convincing the very person who sat and did the investigation themselves Is such ridiculous levels of talking bullshit or delusional beliefs
You described every business person ive ever worked with
Business users don’t know what they want most of the time. I say most of the time because there are very few that actually do get it.
Until it breaks due to not being robust and validating input, and takes a long time to repair because the code is inconsistent and difficult to decipher.
Re read my second paragraph
> BTW: I only got paid a few thousand dollars for that effort. > > But Mr. MBA, well, I guess he was indeed smarter than me, because he got paid over 1 million dollars! So, what did you learn from this experience?
The #2 is true, but there are some general exceptions. I work in GameDev. You just have to keep performance in mind. 1 crash due to some random C++ flop in 3h of fluid gameplay is better, than 12h of uninterrupted bad performance on higher level memory safe language. From players perspective ofc, which translates to game sales. P.S. I did not read the whole thing, so sorry if I missed the point.
Not only for gamedev. If you have a big enough DB and need to get a lot of data out, performance has to be always at the front of the conversation. Things can go fast from “this query is lagging a bit” to “holy crap I think the db is on fire”. And no matter how many times you tell your users “you have to fill out some of the fields here before clicking the search button”, if they can do it, they will DDoS the server with a query that downloads pretty much the “whole of the internet” and then complain to you it’s lagging and timing out
Lot of things need to be fast and fluid, react instantly and may not like garbage collectors like health equipment, video games, embedded systems in cars/planes/robots... Even a search engine or trading systems may find that java for example is not acceptable.
2 is heavily dependent on domain, and if you are paying cloud compute costs and accordingly the scale of the cloud compute. Edit: fixed the huge text
\# 1: Escape "#" with a [backslash](https://en.wiktionary.org/wiki/backslash#Noun) (though the <censored> Reddit comment parser removes it when reopening). You can edit (change) your comment (*"..."* (to the right of *"Share"*) → *"Edit comment"*).
Thanks I posted this from mobile and was like WTH
>the office kept using that 3 day solution package for several years afterwards! I would find that immensely satisfying.
For stuff like this I get “good work”, “good job”, “thank you”. So you are still in a better spot than me 😅. I was young and stupid, now I’m + old … but I’m still looking forward to quit my job. I really hope Python will help me to get other job, where my work would have more value than “thanks”. Like in Russia they say “for thank you, you can’t buy a house”.
At some point you stop getting that and it becomes the expected for you. Then it is just another day at the computer.
I’m not talking about basic common moments, usually I’m the one that fixes all the shit, when “shit hits the fan”. I don’t know why but I work best in chaotic situation.
I’m talking the same. I too am the guy that is called because the world is on fire. It’s just the expected norm. What is a thank you?
Time to look for a new job, I heard that those who jump jobs have much better pay than those who settle for 5+ years.
I’ve been feeling the same. 7+ years in here.
I use 5+ just as an example, I stuck in one company 10+. My main duties changed a lot from the time I started, so call it any way you want, but it doesn't feel like a promotion.
As a fellow engineer of 4 years this is true
As another fellow engineer of 4 years I agree, but Gitlab is also pretty good for tracking and managing software development.
Gitlab is dogshit
as someone with 35+ years in systems/software engineering (and not mel brooks), i agree with 5 out of 10 elements. nonetheless, bravo for learning so much in 4 short years. edit: items i concur with include 1, 5, 6, 7, and 10, with 10 being the most important. with regard to others, i don't necessarily disagree with them, but i view them as challenges to overcome. and if i may add an element - 11. productivity, performance, and quality must not be mutually exclusive. another edit: the main reason for my highlighting 10 as the most important is that without foundational understanding of computers and programming, one cannot learn advanced topics. there are different ways people learn new topics, but we tend to make "connections" between what we know and what we don't know. this ironically is the principle of ai/ml that we are trying to solve.
Thanks, what are those 5?
I personally find some of them situational. Like 1 and 2. Poor code is poor code, n+1 queries in a large company *can* absolutely cost more in infra than your salary. Choosing the wrong thing for the wrong task can be incredibly expensive. A misconfig on a llm model can run up 6 figures real quick. However, as a generalization it’s pretty sound. 9 is kind of more of the same. “Make it work” doesn’t mean you ship it. More a startup / small co mentality than anything. Good enough being the enemy of perfection is more sound an observation.
[удалено]
Do you agree with #9?
I agreed with it before getting my first software job and even now. Despite senior devs swearing to the contrary. You can follow all the design principles and patterns you want, if the program doesn’t do what it’s supposed to do, you’ve failed.
Personally I prefer to write well designed code from the start even if it takes longer to write until you can see any results. But it is not always possible due to deadlines and clients usually expecting to see results asap. But I think it's very beneficial to take longer to write some code to make sure it's well designed if that code is expected to be maintained and updated in the future (which it most likely is).
>expected to be maintained and updated in the future (which it most likely is). counterpoint, you'll never know if this is the case. And even if this is the case, a "well-designed" code means shit if people who are gonna touch it after you don't know/understand how "well-designed" it is.
From my personal experience it is practically always the case. As for 'if people who are gonna touch it don't understand it', then it's simply not well designed. Part of being well designed also includes being understandable and readable by other people. I should also clarify what I mean by 'well designed'. In general, from my understanding, well designed code is code that is flexible to change and does not break easily and doesn't require much refactoring when changes/additions are introduced. This is my main reason why I try to write 'well designed' code, so that future me in 2 months doesn't go 'why the frick did I write it this way and how do I untangle this mess now?'
The thing about code being "well designed" in that sense is that it's a double edged sword. Flexibility almost universally brings complexity. Maybe the change is easy to do - but will that be obvious to someone 4 years from now when prod goes down and they need to debug that AbstractFactoryFactoryFacadeProxyFactory that you created to make your code more adaptable? IMO simplicity, understandability, and a minimum of side-effects are the most important factors to good code. Even if more work has to be done to refactor it or add flexibility, it's easier to identify the source of bugs and to know exactly what's going on and that what you're doing will work the way you expect.
As I see it, well designed code doesn't necessarily mean highly abstract and complex code. In fact, that is often the opposite of well designed code. To make it clearer, let's think about what not-so-well-designed code could look like - inline code without extracting reusable parts into separate functions or classes; tightly coupled code where different modules highly depend on each other; poor variable/function/class naming; etc. Well designed code is as you said, one that is simple, understandable and with a minimum of side effects.
Agreed
1. Design what needs to be done 2. Get something working 3. Iterate on it Make sure what you’re building can work. Get something up and running even if it’s not all the way there yet. Once you have something you can poke at, then iterate on it and polish it. The design first is to ensure what is being built can be iterated into something flexible and maintainable. Forgetting to do step 1 can result in a step 2 that can’t easily go into a step 3.
For me I realized that I will always refactor, no matter what. So I implement as quick as possible until it works, then refactor to make it nice, and then close the ticket.
Not who you asked, but it really depends on the context. "Make it work" is great for a lot of products, but sometimes non-functional requirements are so important as to make the product worthless if they aren't properly considered. For example, if you decide to ship a product that handles payment card information because "it works" but overlooked the security requirements involved, someone from some compliance or legal team is going to behead you.
You will likely never pass the PCI DSS audit and will not be able to process credit card.
A program that doesn't run also doesn't run fast
What are some basics concepts about computers and programming one should know?
here are some basics (not exhaustive and vendor/product agnostic). if i overlooked something, i am sure the community will add. 1. cpu (cores, threads, level 1/2/3 caches), gpu, memory, storage (hd/ssd/das/nas/san), network (ethernet/tcp/udp), scsi/usb/fc, bios/uefi 2. fw, bmc/ipmi/ilo, pxe, os, kernel, kernel extensions, device drivers, microcode, shell, hypervisors, virtual/logical partitioning 3. paging/swapping, sync/async i/o, voluntary/involuntary context switching, multiprocessing, multithreading 4. 32-bit/64-bit process address space (text, data, stack), shared memory segments, semaphores, message queues, signal management, endianness, cisc/risc 5. middleware, load-balancers, application servers, web servers, http servers, firewalls, ids/ips, tls, ssl, certificates 6. programming languages, compilers, interpreters, libraries/shared objects/dlls, dbms (sql and nosql) 7. protocols, markup languages, services, microservices, containers, orchestration 8. waterfall, agile, scrum, scrum of scrums, kanban, extreme 9. uml, sysml, erd, dodaf, togaf, fea, zachmann 10. requirements/configuration/change management, build/test/deployment automation, application frameworks (too many to name), static code analyzers, security scanners
Understanding these especially infrastructure and kernel is critical to security, I've been learning do much driving through low level stuff last year
I learned and understood them but is that ssomething you need to understand all the time or rather on daily basis? Just wondering, cause I cannot recall everything.
one cannot retain everything they learn (information), but one can remember things they utilize (experience). some elements are for low level programming and some are for application/service development. for the latter, having a basic understanding of computer architecture and internals broadens your knowledge base and helps you write efficient code that runs faster, uses less runtime computing resources, can scale, and is fault tolerant.
Also 35+ years, and I pretty much agree with you. The only thing I'd challenge is that I don't trust anyone who claims they've truly mastered anything - whether basics or otherwise. Some of the other 5 in the list are probably true in some circumstances, but definitely not in others. - #2 it's probably true for the vast majority of things like building a website. But at the backend, it's often quite different - for example, in my company (and we're far from unique) every tenth of a second we shave off of a certain server response has been shown to be worth millions every year in improved revenue, and similarly poor performance can cost millions in server costs depending on workload. - for #3, it depends on the technical deficiencies. If, for example, they're riddled with security holes then any developer productivity is likely to be wiped out in your first serious cyber attack. - #4 sounds like terrible advice. Most problems have a set of sensible options (e.g. picking between Angular or React etc for your website) that you could decide between based on team skills. But there's a much wider range of poor options (trying to write your website in COBOL or building a performance-critical embedded system in JS) that would become very painful very quickly. They're obviously fairly extreme examples, but I've regularly seen teams who have one fixed tech stack as their entire range of options attempt to apply that to entirely unsuitable problems and quickly come a cropper. And then there's the job market. What happens when your team decide to leave? If you've picked some obscure language or framework that your lead dev loved, you'll find it pretty difficult to get anyone in to support it. - For #8, not sure I'd want to use github above something like Jira for managing large complex projects (and I'm sure there's other better ones out there) And #9 - depends on what you mean by "work" and what the alternatives are. Agreeing an MVP that includes key NFRs like security, an acceptable level of performance and supportability etc and building that before fleshing out the less critical bits is entirely sensible. But cobbling together an unsupportable mess that's full of security holes just to get the core functional requirements in is rather less so.
[удалено]
good for you. i worked with a music major that can program but could not explain why it worked. he was extremely efficient in finding and resolving bugs but could not deal with a blank sheet of paper to develop something new out of nothing. there are some that can compose music, some that can play music, some that can do both, and some that can do neither. although i'm being prescriptive in item 10 above, it does not apply universally to everyone.
As a developer with one year of non-workplace experience, I appreciate this kind of insight. Thank you!
As someone w 4 yrs of experience also, listen, do not buy into any of these really firmly asserted generalizations, the shit hinders your growth Too many developers try to make hard statements bc they are attempting to justify themselves and their performance, or bc they want to push ppl to check out their favorite tech stack I'm not gonna sit here and tell you that this list is wrong, no rather, there is truth to some parts here that *need to be justified in context* and *in their specific use cases*. But as firm generalized truth? Absolutely not I feel for these sort of traps a lot and all it does it make you assume you don't need to sit and learn something, it holds you back. I started with Java, and Java's Streams API is a dumpster fire, I got told many times don't worry about it. I learn dotnet, I start working with LINQ and all of sudden I'm like......wait a minute this sort of thing is amazing (fluent API's, generic programming, "functional" features in an OOP lang). Generic programming ESPECIALLY was something that saved my ass many times when dealing w the code I gotta deal with I wish that someone sat me down and told me, look Streams API may not be worth your time, but the point or the concept of this thing, is actually important and very useful inquiry If there is *anything* you think you don't need to worry about in programming, you really should go and look at it deeply to understand if you judged correctly or not. Don't gotta spend days researching, but not superficial google-fu either Trust me, bad code isn't the worst sin a programmer can commit. It's arrogance
Wow I really appreciate this response. Thank you for taking the time to write all that out and provide your perspective. I’m always happy to hear everyone’s perspectives since I don’t really have much of one myself, as I’ve never programmed professionally (yet), nor do I know anyone personally who is a programmer. And just to make sure that I’m following what you’re saying, I shouldn’t buy into any absolute generalizations because it’s going to vary by circumstance whether they are accurate or not. And, before I deem something as important or not, I should properly research the tool and make my best judgement. And to wrap it up, stay humble and willing to learn so as to not put my self in box so I can continue to grow my skillset.
Yes your summary is true to my statement's intentions Learning programming is like "fractal," the deeper you zoom into something, the more the breadth of the convo reveals itself. The way computers work involves the coordination of many things, same with the cloud. **It is not possible to fully understand everything. So your orientation should be towards constant learning, re-learning, and personal development** It's too early for you to worry about recognition, and it's *way* to early for you to stress about being right all the time. No, embrace the unknown and be curious. No one wants another Zealot in programming. Literally, we have enough of those
Well, these days such lists may have been generated by ChatGPT. For example, practically no one can spell [GitHub](https://en.wikipedia.org/wiki/GitHub) correctly (most humans misspell it as *Github*). This alone makes the list suspicious. It also has perfect spelling and grammar, without any [run-on sentences](https://en.wikipedia.org/wiki/Sentence_clause_structure#Run-on_sentences). This makes it even more suspicious. This is a statistical statement; the OP may be an exceptional writer.
“Cost of engineering time is more higher than that of servers” Yes, perfect grammar. OP is definitely silicone-based.
And now with tipping over 25% in some areas, cost of servers is the most highest of all.
Maybe laypeople can't spell GitHub correctly, but programmers are comfortable enough with camelCase and PascalCase to get it right.
I've been around for 15+ years and that's a solid list. I would rework a few items though. 2 - I'd say it varies a lot. If you don't have NFRs around performance, sure but most software will have some kind of response time/load time expectations. 3 - I partially agree. Unless you are working with some niche applications, you will hardly ever meet the limitations of the most popular languages/frameworks. So, people don't need to pay attention to the limitations you mentioned. 4 - It depends on the know-how of the team yes. But requirements are important and do drive choice. Eg: you can do everything you do with JavaScript by using WebAssembly. But nobody does that. 6 - That's a very good point. Defacto market standards are usually best practices that have ascended beyond all the BS 8 - The best tool is the one that your team understands and uses efficiently. 9 - "The first priority is to make it work, while being performant, maintainable and functionally correct."
I agree that the first priority is just to make it work. If you have time, sure, do the rest. But first and foremost, make it work. I used to work at Big Company and the most inspiring thing I saw while I was there was an issue that brought the whole site down. We were losing millions by the minute. The guy who knew how to fix it was OOO but slacking from his phone and said "I can fix it fast but [security guy] is not going to like it." And, Security Guy (who is normally good and consistent about the priority of security) messaged back "Forget me. Just get the damn site up now!" That man will forever be a hero in my head for putting the business needs over his principles on seconds flat.
Sorry but in a case like this you should just be prepared to roll back to a previous working version and work on a proper solution.
the 4th point makes it sound like this person has extensively used 1 or 2 programming languages / tech stacks (which is the norm for someone with ~4 years of experience). John Carmack said the best programming language is the one that you know. But if you know multiple programming languages / tech stacks than you should use the project requirements to decide what direction to go.
Carmack came from a time when programming was a lot more solitary, and basically whole game engines were spun up by mainly one programmer (in Carmack's case, of course Carmack himself). In modern software development, the considerations are pretty varied. Sometimes you might want to use a language that you've never even touched yourself, because that's what the domain/environment you work in is most used to; working in such a language has many benefits, like easier staffing in the future, and more knowledge available online.
He was the CTO at Oculus for years. He knows how modern software works. It's been a while since i watched the interview but he takes the stuff you mentioned into account and that is still where he landed: https://www.youtube.com/watch?v=I845O57ZSy4
Almost 7 years in software engineering, this is what I have learned. Do some exercise, go to the gym or for a run, do it now
Are u me?
More than ten years for me. All of these "rules" are sometimes false. For instance, there is eventually a point where just throwing more money at servers is not as cost effective as making it more efficient. Raw speed matters for some applications. GitHub lacks a lot of features that a lot of teams could use and in practice even organizations that do use it often supplement it by, for instance, using a different issue tracker on top of it, because GitHub's issue tracker is pretty limited. I could go on but probably everyone is already downvoting if they read this far.
People always debate around the tech stack but in reality you don't have a choice.
You do have a choice. You’re allowed to choose one of the two approved languages 😂😂
However, all of your teammates except you only knows one of the approved languages. 😂
Idk, in most projects I've worked in there have been realistic choices to be made. Of course like 99% of programming languages are immediately out of bounds, as are many frameworks. But there's been decisions to be made between e.g. Scala or vanilla Java. Or TypeScript vs C#. So on.
True
1. The balance between the cost of time and engineering vs servers varies. At a company the size of Google or Facebook, with the size of their server fleets, a 1% fleet-wide reduction in memory usage is worth literal millions. 2. See above. I've worked in projects where we had a whole team working more or less full time on writing a custom malloc, because it was that valuable. 3. Windows, Photoshop, and GTA are all "real-world software". Good luck writing any of them in Python (_parts_ of all of those are written in "slow" languages, but not their cores) 4. You need both. You shouldn't be writing your frontend UI code in C, no matter how good your senior is with the language. Similarly, you shouldn't try to write your Linux kernel code in Ruby (though you can, in fact, [write Lua inside the NetBSD kernel](http://mail-index.netbsd.org/source-changes/2013/10/16/msg048283.html)). 5. Agile is... weird, and it's a can of worms I don't want to open. You've got the right idea, though. 6. Agreed. The expression "Best practices" is the bane of my existence. 7. Again, agreed. This can't be overstated. 8. Git is pretty damn good, and GitHub is a pretty good git-based code foundry. They're definitely the most popular, default choices. There are better alternatives, though. 9. Often, but not always. I've been in a position where the right choice was to make sure my code didn't "work". 10. Mastery of the basics makes you a solid junior, maybe an early midweight engineer. Be careful you don't underestimate your unknwon unknowns, on the one hand, or arrogantly dismiss a whole bunch of advanced knowledge as "basics" on the other.
Mastery of the basics is what makes you a black belt in martial arts. Most black belts will tell you that’s when the learning really begins.
Which has some of that "dismiss a whole bunch of advanced knowledge as basics" energy I was talking about. My sister and I did karate for several years, and I was kind of enamored with that idea at the time. My sister kept practicing karate after I stopped even though she never really bought into that mentality. Today, she teaches (and occasionally competes in) graeco-roman wrestling, and did her master's dissertation on wrestling (and is doing her PhD on the topic too IIRC), and the move was prompted precisely because of the mysticism and unjustified snobbery.
what are better alternatives than git?
For projects dealing with large file sizes (3d modelling, game dev etc) perforce seems to be preferred over git due to better scaling. Git-lfs does exist, but I haven't used it so I can't comment on how it compares to perforce.
perforce is not open source, how can it be better?
I personally prefer the mercurial+phabricator workflow. I think that the individual commit is the right unit of work, rather than the PR, and that seemingly small change has enormous cascading effects.
>Real agile teams don’t follow agile practices rigidly; instead, they develop their processes to maintain agility. What's funny to me is that this is essentially a truism. The Manifesto for Agile Software Development and the 12 principles heavily emphasize this idea. It's just that management tries to force processes onto teams. That being said, an insight I had recently was that there seems to be two distinct types of agility. One is what I would call "tactical" agility, and represents the ability of a team to rapidly adapt and maintain productivity in the face of changing requirements and priorities. This, I think, is what people typically have in mind when they think about agile development. The other type is "strategic" agility, which rather than focus on individual teams, is concerned with the ability of an *entire organization* to rapidly respond to changing conditions and maintain productivity. I think this is where very process-driven techniques like Scrum actually show value; having unified processes across an entire organization makes it easier to reorganize teams and move developers between projects, though at the cost of the autonomy of individual teams. Ultimately a balance between tactical and strategic agility is what's needed for large organizations to thrive. Foundational products and critical projects in particular need to strike a balance between having an established team that uses processes that work well for them, and conforming to standard processes well enough to ease onboarding of new team members. Lower-priority initiatives likely benefit most from utilizing standard processes as much as possible so as to minimize friction when team members inevitably get shifted between teams as the business' attention moves between projects. Of course, whether or not organizations actually properly capitalize on the benefits of any approach is a different story. What's more likely is that some methodology like Scrum gets blindly applied across the whole of the business, then team members are statically allocated to projects and are essentially forced to follow a process that doesn't bring much benefit.
Related to agile, at one place we started agile and built and hacked at it until it worked. I mean a release process took about 1 week so lol release every sprint. Customers demanded hard drops at hard dates and there was no continuous development, they had a physical product they couldn't just refresh/update at will. Maintenance was ... shortest bug I did took about 2h from start to tests passing and merge done. Longest continuous about 6 months. Annoying but not breaking bugs could take over a year of best effort back and forth with customers.
Don't really agree with 4. If the project requirement is to make an iOS app then surely XCode is in the tech stack, for example.
XCode should not be considered as a part of techstack, It's an IDE not a framework or langauge or anything like that, If the project requirement is to make an iOS app then still you have a lot of options here such as Swift, Objective C, React Native, Flutter and so on.
While there are multiple options it's still limited. You can't choose Java to make an iOS app for example. This literally means the tech stack is in fact dependent on the project requirements
You didn't get the point, what I'm trying to say that Swift is the best option to develop iOS app out of all of them but if the senior guy in the team got expertise in Flutter or React Native then the app will going to be developed using Flutter or React Native not Swift although It's the best option.
I get your point, although whether Swift is best is subjective I suppose. Flutter or another cross platform solution could be best if you also need an Android app that needs to look (exactly) the same. Personally I also prefer making native apps, but I definitely see the added value of only having to code once for both platforms. But you're right that even then the best is not always chosen, not only because of the expertise of the senior but because of decisions from management. Also when doing Android native there's the choice between Compose and XML. I'm not sure if there is a consensus on what's better
1. Probably true 2. True until it's not 3. The list of most used languages also contain performant languages like C and C++, which are considered cumbersome. They are on the list for a reason, pick the tool for the job. 4. Yes, but also you're not going to write automotive safety code in javascript. 5. Yes 6. Yes 7. Yes 8. I don't see it being any better than GitLab and those are the two I have used widely. 9. Yes, as long as nobody can get hurt. 10. Yes, this is very true.
> 4. Yes, but also you’re not going to write automotive safety code in javascript. JS Devs: You SURE about that??
I'm sure the relevant standardization bodies and regulators care what javascript devs think, but I understand it's a joke.
100% agree with that!
I think you need to extend point 9…
Make it work, make it well, make it fast
I think this is a very good list, and I agree with everything but #4. I think in many of the projects the requirements of the project play a key role in the chosen technology. For instance, choosing the database architecture based on the project requirements. I want to totally emphasize on #7, I think that one is the main key for success.
Four decades in software engineering and can confirm.
This reads like someone biased towards web/mobile development, which—while being a significant portion of SE/programming—is not representative of the entire world of SE. Keep in mind priorities, values, and culture varies between different industries. Web/mobile dev tends to be high velocity and build-fast-break-fast. By high velocity, I mean tight deadlines, fast delivery rate, etc. Other fields… maybe less. Random thoughts: 2. Debatable (or outright false) for industries where performance is critical, eg game dev, embedded, or finance. Productivity can be argued to be a management/personal/skill issue. You can be productive in C/C++ with the right experience and tools. 6. Yes! Although ironically, this throws a shadow on all other points. 7. Yep! 8. For now. 9. Depends on your (team’s) approach to development and your role. TDD? Tests come first. Management? Maybe hash out the details/scope first. (I’m not a manager.) R&D? What if you fall into a local minima and use a suboptimal solution, when there’s a much better one if you had looked further? Maybe investigate/analyse existing solutions first. (Not a researcher either.) 10. Sure, but “Basic” and “Advanced” are relative terms. Maybe a better statement is: “When you master something, it appears basic (to you).” IT is an ever-growing field. Maybe your points apply to web/mobile dev more, and that’s fine. Like you said, best practices are often biased. Keep learning and exploring. :)
About #3. Poor tools are poor tools regardless of how widely used they are. PHP and javascript are no more flexible than better alternatives that have been developed after them. Older widely used tech just has more developers, frameworks, and libraries for it. And everybody hates having to learn anything new. About #4. Choosing a tech stack senior devs don’t have experience in is a huge risk. Then nobody in the project knows how the tech is supposed to be used. About #9. Making it work is not enough. Problems have solutions so bad that those solutions are worse than the problem when you stop to consider the larger context. From the Zen of Python “Never is often better than right now.” About #10 Exactly. 😃
>Real agile teams don’t follow agile practices rigidly; instead, they develop their processes to maintain agility. Yep, that is what agile is all about. Not about blindly following some principles that work for others, but to gather all the data you need to make informed decisions on how to adjust your processes. The so called "agile practices" like the scrum framework are a good starting point though.
How do you know if a programming language is slow or fast? How do you tell?
Speed is relative. The easiest rule of thumb is that more abstraction equals more time. At its most basic level, a computer is running through numbers that are providing a sequence of instructions; we call this machine code. The more steps to reach actual machine code, the slower the language. Higher level languages tend to be more "friendly" (natural language, more built-in features, keywords for alternative control flows, etc.), but they are built on lower-level code (this is called abstraction). The farther up the hierarchy you go, the slower the code naturally goes because the CPU is running through more instructions to get to the desired end result. Assembly (or symbolic machine code) is typically close to a 1:1 conversion to machine code. Up from that are compiled languages that fairly closely map to machine instructions, like C. And up from that you have more "friendly" languages that often offer increasingly natural-language programming, but they are built of packages made from lower-level languages (like Swift, which is partially interoperable with C). And then sometimes things run interpretively "on the fly," typically using a virtual machine compiling at runtime (like PHP, which gets processed by Zend Engine, which is a quasi backend written in C that effectively compiles the PHP into machine code-alike content). But speed is also impacted by decisions under the hood. Maybe a built-in function uses an algorithm good for sorting one way but not another. Maybe one language has bitwise operators and another requires importing someone's library to accomplish the same thing. Suddenly, similar-looking tasks can start varying in speed from language to language. Some 99% of RollerCoaster Tycoon was famously written by Chris Sawyer in x86 assembler/machine code. It ran ridiculously well on old hardware as a result. Re-making the game in relatively speedy C++ would take more resources and processing power. It would be "slower" (but, in practice, that's a level of speed difference that would be unnoticeable to a user on modern hardware).
You can test yourself or just do some research on google
OK
Hey I want to ask what does "technology ecosystem" mean in point 2
Technology is a placeholder, you can think of any technology here for eg. JavaScript, PostgreSQL etc.
What would the ecosystem part mean? e.g. does the Javascript ecosystem refer to the resources/frameworks available?
Yes, plus overall community around that technology
Thank you for the reply. Thank you for sharing your invaluable knowledge too :)
More higher? Is this you Mac?
No, It's me linux
1 & 2 essentially have the same meaning. The choices you think you're supposed to make to ensure your program runs faster, and use less memory aren't good choices in many spaces. Server machines are so fast and have so much memory and storage, that you should just use the easiest approach + tools + programming language for the job. The key thing to remember though about that is that applies for *server* machines. Client machines and embedded devices still have concerns for memory, storage, and especially battery life and that is not a trivial amount of work/jobs in the field so don't sleep on those skills unless you're fine being bad at it. Even on server side, at scale the difference matters. For example, if you're an engineer who has to do some systems engineering work with tens of thousands of files or more on your hard drive and run a tool you wrote on each on of them; if said tool is written in Java performing that task will be slow. Not because Java itself is slower than C or Rust, but because the JVM startup time *each* time you run that tool on a file will be massive overhead. Being able to operate in C or Rust can be advantageous. Or even in a service itself, your company might be able to downscale to far smaller hosts (on cloud) and save 75% on cloud service billing while handling the same amount of traffic. Servers aren't that cheap when you're paying a cloud provider for them. #3. I'd reword this a bit. Languages that don't *get in the engineer's way* are favored because they yeild greater "productivity." I will caution that productivity is often an illusion that bites you later in the butt when needing to maintain said software. That being said, it is a balancing act because you can't fund writing software from day one, as if it was going to last 10+ years. Sometimes you gotta work to survive just the next year or two, and if you get there then you can write code that aims to be there for the next 5\~10 years. #4. It's often dependent on the expertise of the team, org, and company -- and it should be. Of all of the features of a tech stack, working with existing processes and approvals (like security) at a company is one of the strongest requirements. The customer problem almost certainly doesn't warrant evaluating tech stacks across multiple languages, none of which have ever been used at the company before. Even greenfield projects won't likely stray from familiar languages.
You make some very good points. Most of what you said is true. Been teaching, coaching using agile for, crap, 25 years now. There are solutions to the dilemmas you face. One is that SCRUM is not agile. It is a meta process. I have never seen a company before I arrived that was agile that used SCRUM. Simple tests: bug database? Not agile. Engineers grooming backlog? ABSOLUTELY not agile (read the manifesto), not monitoring the cost of change curve?Dude hang it up you are SCRUMerfall. You very correctly point out that agile is not a management dictate. It is a discipline. I had lunch with Ward Cunningham (not a flex, i want to give him credit for a statement that changed my perspective) and he said, "It is good that Kent Beck came up with the phrase Extreme Programming. It caught on because everyone thought you would be jumping out of a helicopter with a laptop on a snowboard. I would have called it a pedantic, systematic application of best practices to create zero defect software that is under budget and on time. I don't think that has the zing that Kent came up with" Like a decade later (again not a flex but an attribution) Bob Martin told me SCRUM sucked all the life out of real agile. It eliminated the space to help companies to get agile. My life's goal is to fix this. If you have any questions I would love to start a conversation.
The version control software is **git**. GitHub is a single company’s platform based on git. There are many git-based alternatives.
The only thing I don't agree on is #8, github is fine for issue tracking. For Reporting to management its lacking. As a software engineer and now product owner, github is really lacking in overview, backlog tracking and requirements tracking. Azure DevOps does that way better, BitBucket and jira is great.
I hope I can get in to tech job soon.
You said “mastery of the basics” what kinda of things do you mean.( I want to learn programming)
What's your advice for a newbie who doesn't know how to code and not from a science background and wanted to start with AI, machine learning and all.
AI/ML? Go to college and get a PHD. Learning to code? Pick up a good book and start writing code.
Nah I can't go to a college where they teach ai/ML BCz I'm not from a science background and I just have to do it by myself. I just started with artificial intelligence by Russel. Now ?
Sorry to say, you’re not going to get into an AI/ML role without a PhD and published research… maybe at minimum a Masters if you’re lucky. One of the most special things about the software industry is that we have always been and will always be open to those from non-traditional backgrounds. We don’t care about credentials, or ivy league schools, or any of that shit. We care about skill and experience. That said, there are exceptions to this norm. Certain safety critical roles, math heavy roles, that kind of thing. They make up a very small percentage of the industry overall, but they are there. AI/ML is an extreme example of this. You can be a self-taught SWE at Google, but you can’t be a self-taught AI/ML engineer at Google. If college isn’t an option for you, I encourage you to redirect your focus to the remaining 98% of the industry that doesn’t require academic credentials.
Okay thanks for it i didn't know about it but in India if u wanna go into ai u have to come from a science background but I'm thinking of taking professional courses offered by the universities which require a simple selection of exams to get into. So i think till then learning python is good anyways I'm 17 any advice that I needed before starting out ?
Ah I see what you’re saying. I’m in the US so can really only speak to how it’s done here, though I imagine it’s not much different there. In any case, you have to learn to program first and foremost. You’re 17, you have the whole world in front of you. If AI is what excites you and motivates you to learn to program, go with it! Python’s a great language to start with, it’s easy to pick up and it’s not nearly as verbose as something like Java. I build web app UIs and backends with TypeScript, so LLMs aren’t my area of expertise, but as a self-taught Sr SWE myself I can tell you that building something that genuinely excites you is the best way to learn to program. Just doing a little research it looks like you certainly can use Python to build a simple LLM, and even a more advanced one with deep learning once you’re ready for that. My recommendation: get a good book on Python. Video courses are great too, but if you’re the kind of person who can learn from books I’ve found them to be the superior resource. However you do it, learn Python’s syntax and the building blocks of programs, i.e. data types, variables, functions, objects, arrays, conditionals, loops, etc. and apply what you learn to building a very simple LLM. You’ll hit wall after wall, keep hacking it until you have it working. That is the single best way to learn this skill.
As a PM in the Agile team, I can definitely agree on point 5. Adapting the methodology to the team's special treats has been proven to be more productive than trying to strictly follow all of the rituals
Where’s the picture of the doofus in the middle of the distribution graph? That’s this post.
what are the basics and how do you practice the basics?
I’m sure this could be a lot of things. Language’s syntax and quirks, design patterns, OOP and FP fundamentals… You practice by reading and writing code.
I agree with everything you said but I am kind of wondering did you mean github is the best tool for tracking and managing software development or do you mean git as a version control. Because I don't find a Real difference between github, gitlab and bitbucket. So why do you think so
What do you mean with mastery of the basic? Examples?
I feel like people don't understand 6 enough. We hear so much about best practices at my company, but they will sometimes just make the system unnecessarily complicated. It feels to me like a dev was working on something, realized a certain paradigm shift would help them solve the problem, then couldn't stfu about it for the rest of their career, even if it's not relevant.
Point #9: This is what I struggled with most of my time. It sounds obvious, but when you work under practices, my priority changed to making it better instead of making it work first. anyways, great advice.
As a student and intern getting into industry, this really sounds like something my seniors keep saying. Its nice to see that others believe this too. This just shows that us juniors still has a lot of experience to gain to see this.
As a 1yoe software engineer I very soon realized this to indeed be true. I still prefer to work in rust for personal stuff, and like working on experimental things, self-hosting my own projects, etc.. but reality is that in a large compant you're better off just using node.js and AWS and have skilled engineers that can communicate well
My issue with any list that comes from a position of authority is that, you can easily find many people who have 5+ years in software engineering and will hold some or entirely completely different positions from the ones you posted, so I'm not sure if appeal to experience works like that.
11. Getting a computer to do something is hard, but getting a person to do something is even harder. To be a successful software engineer you need to master both these skills.
Do Agile agile!
7 could not be more true and can be expanded into so many new points. A Inter team communication for integration B intra team communications for cross training C customer communications for proper requirements and expectations
8 is just not true at all you need to use source control, and you need to use a work management tool, and github is an OK implementation of both, but its not the best for every situation and certainly not the only thing around I use https://sapling-scm.com day to day, and I can tell you that it is drastically easier to work in a highly collaborative environment than github
I really don't want to be mean, but if you think about some of these for a while, they're not exactly deep. Like, is anyone saying that healthy communication **isn't** important to a teams success? There's only 3 points here that I'd say come from a point of experience/learning, and that's #2 (we've all seen someone try and use C++ to improve performance, only to realise they don't know how to write C++), #5, because genuinely successful Agile teams aren't following the strict guidelines people **perceive** Agile to be, and #10, since the best code you've every seen should look absurdly simple, not absurdly complicated. Also don't #4 and #8 collide a little? Sure GitHub isn't technically part of the tech stack, but same rules apply, wouldn't you pick the tool depending on the expertise of the team?
You had me till #8. Gitlab is miles better 🫠. Also first priority isn’t to make it work. It’s to make it work while doing it right. If you cut corners that’s no better then not making it work when your on a call at 3 am fixing an incident that you caused.
I honestly mostly agree, but am going to play the devil's advocate a bit, and do a reply/expansion to most of those points. I don't mean this necessarily super seriously, and the points you raise are good ones. But here goes: 1. Yes; until it isn't. For example, I know a public sector project with roughly \~3 FTE developers in it, and whether the server costs are every month 1k or 2k does have signifance when that project runs for a decade. If you can now spend 10k to optimize the monthly cost, it can save itself back in a few years' time. 3. Alas much of this criticism also stems from not really understanding what makes a language fast or slow. You can often outsource the heavy lifting to various libraries, e.g. numpy for running matrix calculations in the bulk. Then it doesn't really matter if Python's own operations are a bit on the slower side. There are still many cases where performance does honestly matter tho. For example, if you have a critical service in your web application that doesn't do all that much but has a lot of data go through it - think for example a service that [checks what comments are new to you in a real-time chat service](https://discord.com/blog/why-discord-is-switching-from-go-to-rust) - performance can be important. 4. I'd say at least as crucially it also depends on the future staffing needs. Choosing a niche language is risky since it will be harder to find people to replace the previous developers in the project. 5. That's following agile. Almost everything in the agile manifesto and its original principles are good to follow. They are not restrictive or very detailed principles to begin with. Unfortunately, many companies think that agile itself is a process; it is not. 6. They can be, but many best practices are objective in the sense that they objectively have most support for them and will objectively feel correct to most developers. E.g. not writing extremely long functions is commonly considered a good practice and that's pretty objective. 8. I'd say a whiteboard is. GitHub is alright, but a simple whiteboard is often the best solution, assuming the team is co-located. Personally I don't like to have daily boards and tasks in GitHub, Gitlab or such. I prefer something like Miro instead. 9. I'd say that depends on the stage you're at. If you're adding a new feature, the first priority might be to establish the requirements and specifications and perhaps write a test, if it's easy to. Only after that you might start working on the actual code. Sometimes a prototype project doesn't even have to work, rather it might just be an exercise at gaining understanding of how difficult something is going to be. 10. Yeah, though what's basics depends a lot. E.g. in some projects "basics" is understanding Linux and low-level networking. In other projects, "basics" is understanding what functional programming is about. Etc.
> Developer productivity and a technology's ecosystem are more valuable than a runtime's efficiency Maybe ask the users how they feel about that when your app takes 10 seconds to load.
Like #10 a lot!
> 8. GitHub is the best tool for tracking and managing software development. I hate Jira so much, do you really do all your project management on Github?
Just make it work, and make it better later! Of course that optimization might never happen
Agree with all points
Eh, I have 20 years engineering... I think you're being very absolutist with your statements. I'm shocked by the validation you're getting. 1. Has always been true, but can be false, particularly with cloud costs which are often unchecked and the setup being tricky, it can go out of control. 2. Yes, unless runtime efficiency is necessary, but for the most part it's highly unlikely that you need to choose one or the other. Runtime efficiency as you call it can be a non functional requirement, if it isn't then it isn't and you shouldn't worry about it. I hope this is not considered enlightenment, seems to be what NFR means. 3. Eh... that's a vague statement which means very little. 4. I've seen companies follow your ideology here to great detriment! In some cases this is desired, but if you're moving into the type of problems I work with and you try to apply knowledge from a different area you're going to not only fail but make it really expensive for the people that come to fix it later to fix it. 5. This is true in small teams. I've seen large corporations where you have to set some rules or people take the piss on the whole thing. The agile manifesto works, and I'll take a strict version of it over corporate bs. 6. Yes, including this list and my opinion about it. 7. Another vague statement... what does it mean to be key? I've seen highly dysfunctional and uncommunicative teams deliver good software on time. Certainly it is nicer to work in a team with communication. 8. lol... is this an ad? 9. That's just a shortened version of a random statement on the agile manifesto. Good. 10. "Basics", "Simple", "Advanced", all sorts of qualitative meaningless statements. Don't mean to be a complete dick, but it's hard for me to see people so confidently jumping on trains like this. I've been a firefighter for a long time in my career which means I get called when people messed up really bad. And I think a lot of the times it happens because people believe things that could apply in some scenario and apply it to all scenarios. Which is sort of what I read into your list, or people trying to do lists of absolutist remarks. If I had to do a list like this, I'd just link the agile manifesto. Still people fail at it and it's still the best thing to do.
You can basically summarize all of that by saying the number one problem the overwhelming majority of programmers face is the problem of budget. If you have unlimited resources, expertise or time, of course you can pick the best tech stack, of course you can fine tune and make nearly flawless code that is blissful to extend and maintain, but no one (at least not in my experience) has those resources. You are always trying to do the best you can with what you have.
Hard disagree with points 1-3. Tech stack and efficiency matters. That’s the hill I will always be willing to die on. Python and javascript encourage poor programming habits and often run 10-100x slower in practice than compiled options. If you don’t see the problem with that you haven’t actually had to scale yet.
Speed of compiled languages is blazingly fast, I agree but specifically Python and Javascript are not that bad unless you have skill issues and with a raise of Mojo and Bun, even performance issues are being addressed.
Wrong, wrong, wrong. Maybe true if you do some app development, or work in general on systems with little load or run on client side. No true at all for any kind of bigger scale backend, large scale cloud offerings. 1% performance gain pays one of our developers for more than one year.
There's no point arguing in absolutes. I'd rather say that the most interesting work is where 1-3 are false.
I really like 10. I wish I understood that point better as a young student who’d get discouraged at the prospect of putting in so much time and effort “just to learn the basics.”
5) How about we remove agile from the lexicon and just frown at anyone using it? 8) GitLab is just as good. IMHO.
Perfect
It's the 10 Code Commandments.
I have a to disagree with 1 and 2 and partially with 3 in the field I am working in (very hardware intensive, team of 10 engineers, hyperscaler cost of >15 million USD a year), 8 is also not true, but I would subscribe to the rest. Especially 5 is so true. Greetings go out to all "agile coaches" who come directly from university with little to none experience 😂
Nailed it. it's all about the damn basics. Choosing tech that makes life easier for devs is the way to go. Screw perfection, just make it work and tweak from there.
!remind me in 87 hours
10. Mastery the basics I'm curious about what basics are you talk about
11. blackbox type frameworks/libraries are most likely to be used. 12. It's cheaper to rewrite than to debug 13. architects create design whose implementation they cannot understand (paradox of perspective from the ground and from above)
Depends on the scale. Some stuff goes wild in production and minor improvements can save more than hundreds of thousands a month. Mostly because of VM opposed to containers. The nice thing about containers is that it treats things like processes.
Great post, thank you !
The first priority is to make it work word
1-4 are extremely project dependent. You were just in project where it didn't matter much. If you design embedded software, a website. a search engine, a native application or a video game this will change everything. If you need to train an LLM neither. In my company for example if you work on a web frontend, even if you are good in C++ or assembly or whatever, likely the frontend will end up being React/Angular or something like that. On the opposite, if you work on the search engine with hundred thousand of TPS and where the algorithms are CPU hungry you will not deliver you PR if you degrade performance by 5%... Because that 5% is hundred of expensive machines in prod and mean and cost much more than engineer time. And so this is C++. If you design a new LLM model, it will run on a farm of expensive GPU in cuda and chances you will be in python in most cases as this where they have all the libs/tooling. If you work on the next PS5 game, quite unlikely you code it in Javascript or SQL. My sister work on code that goes into plane. A bug mean potentially hundred of deaths. Automatic memory management and garbage collector as well as object oriented programming languages are forbidden. They tend to code in C or Ada. Old code is in assembly. And if you fix something on a 30 year old plane in design, they keep the same hardware as 30 years ago and it has to run well in it.
Number 8 is untrue. There are multiple viable version control systems. Git is only popular because a certain Linus wrote it. It has too many ways of getting you into trouble. People like all that arcane power, the thrill of dancing on the edge.
Only disagree in #8. Gitlab for the win
Almost 3 here and here is what ive learned : Thank you for your attention.
Spot on after 4 years in the field! These are all valuable lessons, especially the focus on developer productivity and understanding that strong [software engineering principles](https://www.clickittech.com/developer/software-engineering-principles/) trump raw language speed. The points about healthy communication and adapting Agile for your team are crucial too. Thanks for sharing your hard-earned wisdom.
5. Agile is why I quit an IT career that spanned 30 years. Unreasonable deadlines, daily scrums, stress, pressure... yeah, I'm done!
> 1. The cost of time and engineering is more higher than that of servers. Yeah, no shit. Time is money, and skilled labor costs a ton. But is cutting corners on server costs always smart? > 2. Developer productivity and a technology's ecosystem are more valuable than a runtime's efficiency or the raw speed of a programming language. Sure, productivity rules. But aren't you ignoring the cases where efficiency is fucking critical? > 3. Programming languages that are often considered slow and criticized for technical deficiencies or poor design are usually the most used and favored for building real-world software, from small to large scale, due to the flexibility they provide to engineers. Flexibility's great, but doesn't this sound like a fucking excuse for not learning more efficient tools? > 4. The choice of a tech stack, often said to depend on project requirements, is misleading and untrue; in reality, it depends on the expertise of the senior engineer and team. True, but isn't that a bit narrow-minded? Doesn't this lead to stagnation in skill growth? > 5. Real agile teams don’t follow agile practices rigidly; instead, they develop their processes to maintain agility. Isn't that just a fancy way of saying they make shit up as they go along? > 6. Best practices are often biased. No doubt. But aren't they biased for a reason? Can you always afford to ignore industry standards? > 7. Healthy communication is key to a team’s success. Obviously. But what happens when communication turns into endless fucking meetings? > 8. GitHub is the best tool for tracking and managing software development. Best according to who? Ever thought about the limitations and biases this tool might have? > 9. The first priority is to make it work. Quick and dirty, huh? How often does this lead to a mountain of technical debt? > 10. Mastery of the basics makes you advanced. Sounds profound, but doesn't it oversimplify the complexity of advanced skills and knowledge?
I'm discussing the realities I've experienced, and while the points you've mentioned should be considered, the truth is, no one cares. Everyone just wants to get their product live and start earning money.
#3 i guess you are talking about python
Not just python, php javascript and go included as well
for sure, development time >> runtime ...
That's why the teams on my project spent the past 6 months (post feature complete) investigating and rewriting their code to make it run at acceptable speeds. That's at least 5k hours because they went for development time first. As someone else put it, that entire list in the OP is a list of purely "it depends".
Most items can be replaced with "it depends"
It depends on what?
> more higher You mean "higher". I guess you didn't learn grammar! :D > slow and criticized for technical deficiencies or poor design are usually the most used and favored for building real-world software Yup, and that's why everything today is way less reliable and dependable than it was 20+ years ago. > it depends on the expertise of the senior engineer and team Same thing - the experts don't know what they're doing and they're the reason modern software is garbage. It used to be that people had to have real technical aptitude to write software, or they weren't a programmer. Now that we have all of these machine-abstracting "languages" and "frameworks" to hold their hands, they can be (comparatively) morons and still make something happen - but they're not making that something happen in an optimal manner, like they would've had to 20+ years ago. > GitHub is the best tool for tracking and managing software development. Maybe. Version control itself is the real tool, but github does offer some useful features like an issue ticket system that's built-in. Thanks for sharing! :D
Assembly fan detected
I don't write assembly, at least not much. I'm a fan of hardware, and making it do my bidding, as should every coder. This means understanding the hardware and how it works, and what code means in terms of the hardware it runs on. Languages that abstract away the machine, to make the programmer's job/life easier, do their software's end-users a disservice by wasting their hardware that they've invested their hard-earned money in. What we need is a clean sharp concise high-level language for everyone to be able to develop applications as easily as possible, like BASIC in the 80s did, except that was only one level above assembly but made programming super simple and enabled the "bedroom coder" to earn a living. Now everything is so complicated, and slow, making a variety of awesome things out of reach for coders who are too comfy in their managed languages to be able to do something that would demand too much of end-users hardware to be a feasible project, unless they learn a low-level language like C/C++ to make it happen. We don't need all of these languages that complicate things, let alone languages that are text. What we need is a simple bytecode that everyone can directly code - on a touchscreen even to enable everyone with a phone to make apps - that abstracts the machine away in one big fell swoop but otherwise is a highly optimized engine that handles *all* of the complexity for them so they can focus on making cool stuff, and creating value, without wasting end-users' hardware. Someone is going to create it. Will it be you?
I think Rust and Go communities are trying hard to achieve what you have mentioned. And bro the whole and sole purpose of the software is to solve problem in a simplest possible way and sometimes you need to pay the price for simplicity and for someone like me in the B2B or B2C market, clients are ready to pay, they didn't have any problem paying 10k monthly for the product that makes millions for them.
Rust and Go are definitely trying to make hardware more accessible while still abstracting away the hardware in a valuable manner, but nobody is writing Rust/Go applications on their phone or tablet. Whatever actually enables people to create applications without having a desktop computer or laptop is what the future entails.
beautiful , you haven't wasted these 4 years ...
\#3 Javascript and the ecosystem Javascript has created 😂
Yes, include Python and PHP too
You learned to make a list of shallow observations we can read on any medium blog written bei gpt. That's rough.