Sad story about refactoring.
Programmer: I cleaned up the codes, extract reusable methods, reduced repetitive code and improve overall readability and maintainability.
Manager: why the page still display the same.
Programmer: ...

rant? rant!

I work for a company that develops a variety of software solutions for companies of varying sizes. The company has three people in charge, and small teams that each worked on a certain project. 9 months ago I joined the company as a junior developer, and coincidentally, we also started working on our biggest project so far - an online platform for buying groceries from a variety of vendors/merchants and having them be delivered to your doorstep on the same day (hadn't been done to this scale in Estonia yet). One of the people from management joined the team working on that. The company that ordered this is coincidentally being run by one of the richest men in Estonia. The platform included both the actual website for customers to use, a logistics system for routing between the merchants, the warehouse, and the customers, as well as a bunch of mobile apps for the couriers, warehouse personnel, etc. It was built on Node.js with Hapi (for the backend stuff), Angular 2 (for all the UIs, including the apps which are run through a WebView wrapper), and PostgreSQL (for the database). The deadline for the MVP we (read: the management) gave them, but we finished it in about 7 months in a team of five.

The hours were insane, from 10 AM to 10 PM if lucky. When we weren't lucky (which was half of the time, if not more), we had to work until anywhere from 12 PM to 3 AM, sometimes even the whole night. The weekends weren't any better, for the majority of the time we had to put in even more extra hours on the weekends. Luckily, we were paid extra for them, but the salary was no way near fair (the majority of the team earned about 1000€/mo after taxes in a country where junior developers usually earn 1500€/month). Also because of the short deadline given to us, we skipped all the important parts like writing tests, doing CI, code reviews, feature branching/PR's, etc. I tried pushing the team and the management to at least write tests and make feature branches/PRs, but the management always told me that there wasn't enough time to coordinate and work on all that, that we'll do that after launching the MVP, etc. We basically just wrote features, tested them by hand, and pushed into the "test" branch which would later get tested and merged into master.

During development, one of the other juniors managed to write the worst kind of Angular code you could imagine - enormous amounts of duplication, no reusable components (every view contained the everything used in the view, so popups and other parts that should logically be reusable were in every view separately), fuck - even the HTML was broken (the most memorable for me were the "table > tr > div > td" ones, but that's barely scratching the surface). He left a few months into the project, and we had to build upon his shit, ever so slightly trying to fix the shit he produced. This could have definitely been avoided if we did code reviews.

A month after launching the MVP for internal testing, the guy working on the logistics system had burned out and left the company (he's earning more than twice the salary he got here, happy for him, he is a great coder and an even better team player). This could have been avoided if this project had been planned better, but I can't really blame them, since it was the first project they had at this scale (even though they had given longer deadlines for projects way smaller than this).

After we finished and launched the MVP, the second guy from management joined, because he saw we needed extra help. Again I tried to push us into investing the time to write tests for the system (because at this point we had created an unstable cluster fuck of a codebase), but again to no avail. The same "no time, just test it manually for now, we'll do that later when we have time" bullshit from management.

Now, a few weeks ago, the third guy from management joined. He saw what a disaster our whole project was. Him joining was simply a blessing from the skies. He started off by writing migrations using sequelize. I talked to him about writing tests and everything, and he actually listened. He told me that I'm gonna be the one writing them, and also talked to the rest of management about it. I was overjoyed. I could actually hear the bitterness in the voices of the rest of management when they told me how to write the tests, what to test, etc. But I didn't give a flying rat's ass, I was hapi.

I was told to start off by writing a smoke test for the whole client flow using Puppeteer. I got even happier, since I was finally able to again learn new things (this stopped at about 4 or 5 months into the project).

I'm using jest as the framework and started writing the tests in TypeScript. Later I found a library called jest-extended, but it didn't have type defs, so I decided to write them and, for the first time in my life, contribute to the open source community.

I'm a new developer. Here is the top advice I've received:

0. Think like a programmer, outside of work too.

1. Programming is tough. It takes a certain kind of mindset to sit in front of a monitor and think it through a problem till the end. Develop that mindset.

2. Handwork pays.

3. Do it for fun. Be exceptional. Money will follow.

4. Care about the craft you build. Write such a beautiful code that your fellow devs would think about your code and have a nerdgasm.

5. Simple is beautiful. Anybody can make things complex. It takes a stroke of genius to make things simple.

6. Write modular code. It makes your code reusable and easy to maintain. Future developers who will work on your piece of code will appreciate it.

7. Share your knowledge. Unlike materialistic things, knowledge grows when you share it.

8. Add comments. You think you'll remember why you wrote that piece of code that way or a clever hack you created but trust me, you won't.

9. Be humble. You'll never know everything. Don't hesitate to ask for help.

10. Writing code is exciting! Of course there will be some frustrating moments. But don't give up! You'll miss a lot of fun.

I've had my share of incompetent coworkers. In order of appearance:

1. A full stack dev. This one guy never, and I mean NEVER uses relationships in their tables. No indexing, no keys, nada. Couple of months later he was baffled why his page took ten seconds to load.

2. The same dev as (1). Requirement was to create some sort of "theme" feature for a web app. Hacked it by putting !important all over the place.

3. The same dev again. He creates several functions that if the data exists returns a view, and if it doesn't, "echo '0'". No, not return 0 or return false or anything, but fucking echo. This was PHP. If posted a rant about this a few months ago.

4. Same dev, has no idea what clean code is. No, not just reusable functions, he doesn't even get indenting right. Some functions have 4 spaces, some 2 tabs, some 6 tabs! And this is inside the same function. God wait until he tries Python...

5. Same dev now suggests that he become the PM. GM approves (very small company). Assigns me to travel to a client since they needed "technical assistance about the API". Was actually there to lead a UAT session.

Intermezzo, that guy went from fullstack dev to PM to sales (yes, one who calls clients to offer products) to business development, to product analyst in the span of two years.

After a year and a half there, I quit.

6. New company, a "QA engineer" who also assumes the role as the product owner. Does absolutely no tests other than "functional tests" in which he NEVER produces any form of documentation. Not even a set of test cases. He goes by "intuition".

7. Same guy as (6), hands me requirements for a feature. By "hands me" I mean he did that verbally. No spec documents, no slack chat, no Trello card. I ended up writing it as a card in Trello. Fast forward to the due date, he flips out because that wasn't what he wanted. Showed him the card. He walked away, without thinking of a solution how this mess should be handled.

Despite all this, I really don't want him (6&7) to leave the company. The devs get really stressed out at this job and he does make a really good person to laugh with/at.

Among my fellow developers at work, there is one guy who stands out because he actually strives to write modular, reusable and readable code. He literally saved me weeks of development by making his code modular enough that I can simply use it almost like a mixin where I only need to provide an alternative template. Note that the feature I'm talking about is for a pretty much sophisticated business process related to handling credit card data. Others in my workplace would just couple their logic tightly with their feature/scope's views.

I really wanna hug him and be his BFF now. #nohomo tho.

Building a business can hamper one's development urges!

I have been building stuff since 2008. Took my first job in 2012, won a hackathon at Yahoo right after that. Got an amazing team to work with! Our team converted the hacked product into a proper product using Django and AngularJS. Those were the fun days. At that time AngularJS had just come out and I was under the dilemma to use Angular, Ember or backbone. But with all this came the responsibility to build a business out of our product. It didn't happen eventually though.

So I moved on to cure my entrepreneural itch and went on to start up an e-commerce startup along with my day job. It started getting good traction and I finally left my day job to focus completely on it. It's a sticker marketplace and I had to focus a lot on the actual physical product, improve the quality, tackle business development and stuff etc. In all this, my habit of creating stuff with code kind of got the back seat. Everyday, I see such exciting technologies come up and I want to try them out. I have been itching to create a native app using react native. Try to build a skill for Amazon Alexa.

On one side I am happy that I have been able to build a brand and become the largest sticker marketplace in India providing super awesome reusable stickers, but on the other hand, managing the business on a daily basis is killing the developer in me :(

Does anyone else building a business which involves a physical product also face a similar problem? I think I should just take up weekend hackathon type problems and try to solve them using the technologies I want to learn. Example, I have been meaning to build an app for our company. I think I will start with that!

I have been following devRant for quite sometime now and it has been awesome. Finally, signed up and ranted today! 😊😊

Me: let's implement reusable code
Them: Fuck no...

***brawl***
🤦🏽‍♂️

I am much too tired to go into details, probably because I left the office at 11:15pm, but I finally finished a feature. It doesn't even sound like a particularly large or complicated feature. It sounds like a simple, 1-2 day feature until you look at it closely.

It took me an entire fucking week. and all the while I was coaching a junior dev who had just picked up Rails and was building something very similar.

It's the model, controller, and UI for creating a parent object along with 0-n child objects, with default children suggestions, a fancy ui including the ability to dynamically add/remove children via buttons. and have the entire happy family save nicely and atomically on the backend. Plus a detailed-but-simple listing for non-technicals including some absolutely nontrivial css acrobatics.

After getting about 90% of everything built and working and beautiful, I learned that Rails does quite a bit of this for you, through `accepts_nested_params_for :collection`. But that requires very specific form input namespacing, and building that out correctly is flipping difficult. It's not like I could find good examples anywhere, either. I looked for hours. I finally found a rails tutorial vide linked from a comment on a SO answer from five years ago, and mashed its oversimplified and dated examples with the newer documentation, and worked around the issues that of course arose from that disasterous paring.

like.
I needed to store a template of the child object markup somewhere, yeah? The video had me trying to store all of the markup in a `data-fields=" "` attrib. wth? I tried storing it as a string and injecting it into javascript, but that didn't work either. parsing errors! yay! good job, you two.

So I ended up storing the markup (rendered from a rails partial) in an html comment of all things, and pulling the markup out of the comment and gsubbing its IDs on document load. This has the annoying effect of preventing me from using html comments in that partial (not that i really use them anyway, but.)

Just.
Every step of the way on building this was another mountain climb.
* singular vs plural naming and routing, and named routes. and dealing with issues arising from existing incorrect pluralization.
* reverse polymorphic relation (child -> x parent)
* The testing suite is incompatible with the new rails6. There is no fix. None. I checked. Nope. Not happening.
* Rails6 randomly and constantly crashes and/or caches random things (including arbitrary code changes) in development mode (and only development mode) when working with multiple databases.
* nested form builders
* styling a fucking checkbox
* Making that checkbox (rather, its label and container div) into a sexy animated slider
* passing data and locals to and between partials
* misleading documentation
* building the partials to be self-contained and reusable
* coercing form builders into namespacing nested html inputs the way Rails expects
* input namespacing redux, now with nested form builders too!
* Figuring out how to generate markup for an empty child when I'm no longer rendering the children myself
* Figuring out where the fuck to put the blank child template markup so it's accessible, has the right namespacing, and is not submitted with everything else
* Figuring out how the fuck to read an html comment with JS
* nested strong params
* nested strong params
* nested fucking strong params
* caching parsed children's data on parent when the whole thing is bloody atomic.
* Converting datetimes from/to milliseconds on save/load
* CSS and bootstrap collisions
* CSS and bootstrap stupidity
* Reinventing the entire multi-child / nested params / atomic creating/updating/deleting feature on my own before discovering Rails can do that for you.

Just.
I am so glad it's working.
I don't even feel relieved. I just feel exhausted.

But it's done.
finally.

and it's done well. It's all self-contained and reusable, it's easy to read, has separate styling and reusable partials, etc. It's a two line copy/paste drop-in for any other model that needs it. Two lines and it just works, and even tells you if you screwed up.

I'm incredibly proud of everything that went into this.
But mostly I'm just incredibly tired.

Time for some well-deserved sleep.

> Last year wrote a unittest - I was asked to delete it
> no design patterns. Not a single one
> no encapsulation
> fucked up inheritance [I had no idea it was possible at all...]
> generics every-fucking-where
> I could go on...

this month the lead dev was not in and I had to make a new feature. Guess what I did :)

tdd [coverage >90%], a couple of builders, a factory or two, two composites, one decorator, only a few generics - only where really needed. Private fields, not a single @Autowired field [they were fucking my tdd], nicely abstracted integrations, and so on. Everything is writen according to clean code: max 10loc methods, <140col lines, reusable constants and utils, SOLID as a rock, etc.

Due date is next week. Took me 3 weeks to craft it.

Guess who's gonna be piiiiiiiiiiiiisssedd 😁

the best part - I don't even work there, our company was hired for xx hours as helping hands 😁

that's not all. They have like 6 envs and their deployment is all-fucking-manual. Will try to learn how to dockerize that app and deploy it on docker. Gosh I wish I could see his face when he's back 😁

p.S. From ethical point of view, he's the only dev who believes his code is perfect. No other dev in the team agrees. AND he once said: 'it's gonna be my way or no way at all'. So I don't think I did wrong... Did I? :)

I have been creating mods for Skyrim and Fallout for a few years now. One day another modder wanted to make his own game using Unreal Engine 4. I wanted to learn UE4 anyway and the other members have made many mods before, so I joined in.

Well, it turned out I was the only one with a professional programming background (this is where I should have run). The others were all modders who somehow got their shit working. "It works, so it's good enough right?" On top of that UE4 has a visual scripting system called Blueprint. Instead of writing code you connect function blocks with execution lines. Needles to say that spaghetti code gets a whole new meening.

There was no issue board, no concept, no plan what the game should look like. Everyone was just doing whatever he wants and adding tons of gameplay mechanics. Gameplay mechanics that I had to redo because they where not reusable, not maintainable or/and poorly performing.

Coming from a modding background, they wanted to make the game moddable. This was the #1 priority. The game can only load "cooked" assets when it got packaged. So to make modding possible, we needed to include the unpacked project files in the download. This made the download size grow to 20+ GB. 20 GB for a fucking sidescroller. Now, 1 year after release we have one mod online: Our own test mod.

Well we "finished" the game eventually and it got released on Steam. A 20 GB sidescroller for $6.99. It's more like a $2.99 game in my opinion. But instead of lowering the price they increased it to $9.99, because we have spent so much time creating the game. Since that we selled less than 5 more copies. And now they want to make it work on mobile. Guess who will definetly NOT help them.

I have spent ~6 month of my freetime for this project, my rev share is < 100€ and they got me a lot of headaches with all their dumb decisions. Lesson learned. But hey, I am pretty good with UE4 now.

Best tool:
Your hands!
- incredibly flexible
- express a lot of commands trough very little code (just raise the middle finger and tell me if you are not expressing something VERY strong with VERY little complexity)
- reusable
- interfaces
- smells of good soap

Worst tool:
Your brain
- highly power consuming
- wrinkly, ehw!
- overthinks a lot
- imposter syndrome
- hooked on sugar like it was cocaine
- hooked on cocaine like it was sugar
- refuses to comprehend chthulu

Question everything!

Comments lie.. sometimes code does too.. Customers..they lie the most..and are sloppy..

Don't be like customers, don't be sloppy. If you were sloppy own it & don't lie about it!

Pick your fights (trying to fix vs rewrite the shit out of it)..you will know what to do more with experience..

RTFM & docs.. If things still unclear, ask before your dick gets stuck in a toaster!

Ask away, learn about the customers & how they use your product.. you'll be surprised how something intuitive to you might be a rocket science for them..meaning more room to fuck things up when using it..more ways you can adapt & prevent things..

Most of all, don't fuckin lie.. ever!!
If you lie on you're CV, we will find out.. If you fuck up something & lie about it, we will find out.. but it will cost us precious time when solving it from scratch.. People fuck up..that's a fact..how you go about it is what makes/breaks it for me. So don't ever fuckin lie to me!!

And don't be arogant.. if you complain about fixing bugs, this is not a job for you.. if you can't even fix the obvious ones you've put there in the first place..twice as bad..

So think before you code..what do you want to do, how you want to accomplish this, is it reusable, can it be extended, does it introduce new technology into the project, will it fuck up current setup.. once you have this shit figured out, code will write itself..

Did I mention already you're not to lie to me, ever?!

And don't try talking about me behind my back either..I've seen it backfire before, results were not good..

"I understand you want to write your own code. But that's not professional. If you have reusable tested code just copy and paste it in your project"

I thought he was joking. But I am realising it's the most valuable advice in jy workplace

Been really busy with things haven’t got around to posting a book in like a week or so..

But I’ll post one today..

This book...

This book, available for free online or you can buy it, written in 1994. But so under appreciated by people for some reason most people never have seen it or know about it. But this is the ONLY book I know of that actually covers this topic.. the only book in existence that specifically goes thru how OOP can be done with C.

NOW hold up before you say just use C++ stop and think for a second.. bear with me.

First off this book is purely for informational purposes and educational use to deepen your understanding of what OOP is actually doing behind the scenes in languages like C++ where keywords exist for these things and you just blindly use them without thinking about under the hood.

This book contains a lot of code and builds you up a complexly library from scratch to make OOP in C... now I don’t take this book literally and this but I have implemented some concepts from this book in projects in the past, and it helps a lot.

Also in my honest opinion If you finish this book, you will be a better C programmer AND c++ programmer, C programming because it teaches you a lot about complex things that you never thought about doing with the language. It proves you can do polymorphism can do inheritance and encapsulation. And it’s not really bloated either.

This books is an awesome book, if you don’t understand C pointers you definitely will after this book.. if you don’t understand OOP in C++ what’s really going on.. you will after this book. After all C++ began as just a preprocessor of C.

Great book for writing reusable, extendable large scale embedded c systems.

Anyway.. rare book of which should not be rare considering it’s free.

I never thought clean architecture concepts and low complicity, maintainable, readable, robust style of software was going to be such a difficult concept to get across seasoned engineers on my team... You’d think they would understand how their current style isn’t portable, nor reusable, and a pain in the ass to maintain. Compared to what I was proposing.

I even walked them thru one of projects I rewrote.. and the biggest complaint was too many files to maintain.. coming from the guy who literally puts everything in main.c and almost the entire application in the main function....

Arguing with me telling me “main is the application... it’s where all the application code goes... if you don’t put your entire application in main.. then you are doing it wrong.. wtf else would main be for then..”....

Dude ... main is just the default entry point from the linker/startup assembly file... fucken name it bananas it will still work.. it’s just a god damn entry point.

Trying to reiterate to him to stop arrow head programming / enormous nested ifs is unacceptable...

Also trying to explain to him, his code is a good “get it working” first draft system.... but for production it should be refactored for maintainability.

Uggghhhh these “veteran” engineers think because nobody has challenged their ways their style is they proper style.... and don’t understand how their code doesn’t meet certain audit-able standards .

You’d also think the resent software audit would have shed some light..... noooo to them the auditor “doesn’t know what he’s talking about” ... BULLSHIT!

I am just sick of the things that's been going on.

Joined a mid level startup as full Stack developer working on angular and node js . Code base is too shit and application is full of bugs(100+ tickets are being raised for bugs)

Since the product owner(PO) wants to demo the application he is pushing for bug fixes.

UI code:
1. Application is not handled for responsiveness all these years, it is now being trying to address. Code base is very huge to address though .
2. The common reusable components of UI has business logic inside. Any small change in business logic we are forced to handle in common components which might break up on another components.
3. Styling in 40+ components are made global. Small css change in component A is breaking up in component B due to this
4. No time to refactor.
5. Application not at all tested properly all these years. PO wants a stable build.
6. More importantly most of developers have already left the company and we are left with 2 developers including me.

I am not in a position to switch due to other commitments adds up a lot to frustration

When the code you wrote 3 months ago is actually reusable else were in your program #OOP

i was hired to join a team of old devs (40+) in an unnamed European country "yay goodbye 3rd world it's time to enjoy the quality of life" assist with enhancing already existing software and creating new solutions.
prior to my arrival most things were slow and super buggy, looking at the code base it shouldn't be a surprise, amateur hour everyone, logic implemented that is not needed, comment driven development, last time code review was done back in 1996. lots of anti patterns.
i swear there is a for loop that does nothing but it loops through a 100+ elements list, trunk based development with tfs since git is "not really needed"
test projects are not there.
>enter me an educated fool, with genuine passion for the craft and somehow a decent amount of knowledge.
>spent the last year fixing stuff educating people on principles and qualities.
> countless hours of training and explaining. team is showing cooperation, a new requirement comes in to develop with react.
> tear my ass creating reusable shit and self explanatory code with proper naming etc using git with feature branching, monday is first deployment day.
> today a colleague was working on an item submit a pull request and self approve it
> look at the code..... WTF the dumb fuck copied and pasted the whole code from different kendo components but somehow managed to refractor the name to test component, commented out all the code that he didn't use did the api call directly from the component, has 2 useeffects that depends on the a fucking text box changes for no reason, no redux implementation, the acceptance criteria is not achieved, and it doesn't work it just look right.
> first world country shit cannot scold, cannot complain, lead by example.
>asked him why you did this, the response was yeah probably i shouldn't have done that, i really didn't understand anything in the training but didn't want to waste time!!!!
> rest of the team created a different styled disaster with different flavors they don't even name their shit the same way.

fellow developers I'm stuck in a spaceship with a bunch of imposters, seriously i never cried in my entire life now I'm teary and on the verge of a break down.
talk with management "improving needs time" and offers me to join a yoga session to release the stress as if reaching nirvana would deliver shit on monday.
i really don't know what do is this a rant, is this a cry for help, I'm not sure, any advice is welcomed.

Spent 2 days refactoring code written by our "offshore team". I've done refactoring on the same code in the past, probably upto about a week in total of refactoring now. The code looked like it was written by someone who had literally just finished their first "Hello World" app - loads of code blocks copied and pasted instead of declaring reusable functions.
The whole thing should have been done by us in the first place.
And yet our money-conscious company wants to employ more of these developers. Cheaper than us? Sure. Quantity over quality though, but I guess money is all that matters to the big cheese

Me: here is my idea with the code. Does it follow what you had in mind?
Dev lead : this is good...really good but if you could take everything you have here and make it a reusable module that would be great!
Me: so it is or isn't what you had in mind?
Dev lead :: it is but I need you to change it all.
Me....FML

I just finished designing an entire asset management pipeline and christ on a fucking pogo stick, if it isn't convoluted.

Theres a lot of game engines out there, but all of them do it a little different. They all tackle a slightly different problem, without even realizing it.

1. asset management

2. asset change management

3. behavior change management

4. data management

5. combinatorial design management.

6. Combinatorial Behavior management

7. Feature completion

ASSET MANAGEMENT is exactly what it says on the tin.

ASSET CHANGE management can be thought of handling the import, export, formatting, platform specific packing, and versioning (including forking) of an asset.

BEHAVIORAL CHANGE management is a subset of asset management, because code is a subset of assets (depending on how you define 'assets'). The oldest known example of this is commenting and uncommenting code.
Or worse, printf debugging.

This can be file versioning, basic undo services, graph management of forks and mergers, toggles for features or modules, etc.

DATA management is about anything that doesn't fall into the other categories, everything from mission text to npc dialogues, quests, location names, item stats, the works. Anything you'd be tempted to put in a database, falls under this category. Haven't yet seen many engines offer this as an explicit built in tool as of yet, because the other problems are non-trivial as is, so this is a bit of low hanging fruit that gets handled by external tools, or loaded from formats as simple as json.

COMBINATORIAL DESIGN management is the idea of prefabbing, blueprints of broader object design using nested prototypes of existing game objects, to create more complex, reusable set pieces. Unity did this well. GM does this in part.

COMBINATORIAL BEHAVIOR management is entity-component systems, plus tooling to make it easy to add, remove, and configure components and their values on entity blueprints, also not uncommon. Both stencyl and unity do this. GM has a precursor to this in the form of configurable fields, but these fields are not based on component scripts attached to objects.

FEATURE COMPLETION is that set of gameplay mechanics or styles of design that an engine naturally makes easier to include or build in a game.

I don't think I'm aiming for all that, but I think at minimum a good engine has to do asset management, behavioral change management, prefabs, and entity-component systems with management tools for that. And ideally, asset change management.

I really hate sales people. My stakeholder wants to buy an address verification service but is hesitant to purchase now because the dev time needed would be substantial. Now the sales rep has planted seeds of doubt in my SH and SH thinks I grossly overestimated the labor I quoted.

Sales rep is all “major corporations have installed this in a weekend.” 🤬🤬🤬 Major corporations also have more than one developer and probably aren’t dealing with a website that has a dozen address forms that all work differently. Oh, and I DON’T WORK WEEKENDS MOFO.

My SH originally requested a labor estimate for installing the AVS on all address forms and that’s what I delivered. My audit revealed a dozen different forms. I’m working with a legacy code base that’s been bandaged together and maintained by an outside dev agency. The only thing the forms have in common is reusable address fields. They all work differently when it comes to validating and submitting data to the server and they all submit to different api endpoints. At least a quarter of those forms are broken and would need to be fixed (these are mostly admin-facing). I also had to provide an estimate on frontend implementation when I have no idea what they want the FE to look like.

My estimate was 5-8 weeks for implementation AND testing. I wrote up my findings and clearly explained the labor required, why it was needed, and the time needed. All was fine until the sales rep tried to get into SH’s head.

My SH is now asking for a new estimate and hoping for 1-2 weeks of labor, which is what will SH to buy the AVS. Then go to the outside dev agency you used to work with and ask for a second opinion. I’m sure they’d also tell you at least month if not more for testing, implementation, and deployment because you have a DOZEN FORMS you want to add this to. 1-2 weeks is only possible for a single form.

My manager doesn’t work in the same coding language I do, but he read my documentation and supports my original estimate.

I honestly want to ask my SH if this sales rep is giving a very good price for the AVS. If not, are there other companies in the mix? Because right now you have a sales rep that’s taking you for a ride and trying to pressure you all so he can get another notch in his belt for getting another “major corporation” as his account. I don’t think it’s a good idea to be locked in with a grimy sales rep.

It’s actually been quite a fun day, after some ranting on one of our slack communities flutter channel, myself and my team realized we were in a really good place to give back.

We have been working on a large scale flutter application for about a year, phase 1 is about done and we at 11k LOC.

We have been doing a big push for testing over the last 2 months and are at about 50% coverage. The thing we realized is that is the 1 place flutter has fallen short with documentation.

Very little about what we learned for testing our code came out of a google search, or it came out of cobbling bits together from numerous searches and sources.

So we decided we are going to plan and host a virtual meetup to discuss what we have learned and hopefully teach a few people some useful things and hopefully also learn a few new things too.

In addition, and as it has a longer shelf life, we going to setup a medium publication for the company and start a series to cover small specific topics, specific use cases or scenarios that we had trouble with and solved.

Today I had my first thing to type out, had worked out how to test that a function that was passed into a widget was called. So the parent passes the child and onTap function but you are testing the child not the parent as the child is reusable...

Anyway, so with that idea I got hold of marketing for some assets, setup the publication and proceeded to type out 3 articles today, all nice short ones under 2 min reading time.

It really is nice to give back, it’s not like I am Remi smart and can go and write BLoC, but I am smart enough to figure shit out and type it up so that the next guy hopefully benefits from my brain bashing.

We're making reusable rockets and putting cars in space but I still can't pay with my fingerprint instead of a fucking pin code.

Laziness is a mother of reusable code.

So I'm on orders for the Marine Corps, and this one guy thinks he's a programmer because he made a "program" in excel for dispatching our equipment. He's complaining that he's just fixing bugs. I take a look at his VBA code and see literally 1000 lines of if statements bundled into one function. (Or I think they're referred to as sub routines in VBA - it's been a while since I worked with it).

I try to give him some tips and pointers since he's literally just manually checking. Each. F'ing. Cell and a million nested if statements. Tried giving tips on making reusable code, and he has the cojones to tell me he knows what he's doing and doesn't need my "help". Granted I'm higher ranking than him and he also answers in a disrespectful manner.

End rant.

Tbh this is more about education in general... Introduce the same system i had, no fixed lessons just a project and a time frame. Eg : create your own MVC framework and a site to show it off

Time frame : 5 weeks

(dont expect fully fletched frameworks but a site that uses the MVC data flow and the code is reusable)

Just tried out Jupyter Notebook for the first time. I can see why software engineers wouldn't like notebooks, especially if you intend to actually publish the notebook as code for other people to use (please publish a module that can be imported, not a notebook that has to be hacked to pieces to make it reusable), but it's pretty handy for early prototyping or documentation.

I'm playing around with save-editing for a few GBA games as a personal project, and I used a Notebook to document the save file format with examples.

in my previous company , we used to create 4 custom ui states for just 1 screen in android app, and we would have task to create 3-4 new feature screens in 1 sprint (of 14 days) the states would be :

empty state : a state where data is not available. usually consisted of message, a graphic and some action button

data state : the usual state where data is filled on various elements

loading : a shimmer ui showing loading. it was supposed to be pixel perfect to that of the data state. it was basically a different xml, but with grey colored views instead of colorful. the tricky part would usually he to create the dynamic views

error/no connection state : as most of the screens couldbget api error or no internet error, this would be the screen for asking user to retry connection

all of these screens combined with their ui in xmls + kotlin code with barely any stuff being reusable , made the life incredibly difficult. however a lot of our customers would appreciate the interactivity of our app

doing these stuff again nd again , i had become trained to do all those 3-4 (x4) screens and the whole ui stuff in first 4 days of the sprint. but now i am in a company where i am getting passed on to managers after managers and getting tasks to change documentation in 1 week, i find those coding stuff incredibly tough.

gotta get back to shape

The downside of writing reusable, abstracted, DRY code for multiple applications to use: you have to remember to test changes in all the contexts... my org has to hire contractors project by project as we dont have the budget to have more devs than just 1 (me) on permanently. the contractors tho often don't know about all the places our code gets used. And sometimes I even forget - last week in the rush to finish some project, we forgot to think about how a library change made for benefit of a new project a few weeks ago might effect an older (in production) project. Until shit started breaking. Annoying. very annoying. luckily i fixed it (rolled back) before the weekend, but thursday and friday were quite stressful... now tomorrow, a bunch of sleuthing time to figure out exactly what recent change caused it... argh....

CRM

Clean.
Reusable.
Maintainable.

As a POC I removed all client specifics from a project and made it reusable. Thousands of lines of code. In a day. From a project I knew nothing about in a language I previously used only in school. And it compiled and ran in the end.

Ripping out so much useless code felt great, possibly as good as creating something new, fresh, innocent. I improved on performance and maintenability and found some errors in the process.

After a successfull POC it was time to do it properly. That was a nightmare. A horror movie you want to see through. In the end I felt even better.

Ah, the ancient art of copy-paste development – where originality goes to die and bugs come out to play. It's like a cursed incantation that tempts even the best of us into the dark abyss of shortcuts.

You think you're saving time by copying that snippet from Stack Overflow, but little do you know, you've just invited a horde of gremlins into your codebase. Suddenly, your once-cohesive architecture looks like a patchwork quilt sewn by a drunkard.

And let's not forget the thrill of debugging when you realize that the copied code references variables that don't even exist in your context. "Ah, yes, I remember copying this gem at 2 AM. What could possibly go wrong?"

But wait, there's more! Copy-pasting also introduces a special kind of chaos when updates are needed. You find yourself fixing the same bug in five different places because you couldn't be bothered to encapsulate that logic in a reusable function.

So here's a heartfelt salute to all the copy-paste warriors out there, bravely navigating the treacherous waters of borrowed code. May your future coding endeavors involve more thinking, less CTRL+C, and a lot fewer late-night bug hunts!

dammit ti why must your torture be limitless

> eZ80 has awesome DMA-like instruction that copies byte chunks based on registers and it's nigh-instant to copy 64k it's great
> TI has the opcode disabled outside a 4-byte chunk erroneously unincluded from all blacklists and access regulation
> can't bankswitch and keep registers, and can't write to anywhere but those 4 bytes in that bank
> no reusable code in target bank that i can use via mid-func bankswitch

Joined a new company as front end developer after working for a legal tech for 3 years. The codebase is shit here. There is this ReactJS developer who has done everything except for following standard code practices. No modularity, no reusable components. Some files go beyond 2000 lines of codes. It is a literal nightmare.

The worst part is, he does not understand that he has written the worst code. I dunno how to handle this now.

When refactoring and reusing code, is it even ethical to change author?
I am on a project of creating reusable library from another project. Original code is perfectly written, easy to understand. I will just prune the code and fix minor bugs.

I have seen colleagues replacing the original author field in the same scenario with their names, feels wrong. Can I add non-standard maintainer field in doxygen format?

I am now thinking of introducing a new self imposed rule of breaking functions up when they go above 10 lines to ensure I don't have too much happening as I often don't make small enough reusable parts and my code gets too complex. Opinions?

>start new job, not very professionally experienced dev
>spend couple of months working on a feature that is supposed to be an MVP kind of thing, be rushed to finish and told to cut corners because it's "just an MVP", still lose sleep and have relationship suffer (and ultimately ruined) as I try to not lose deadlines created by the boss with questions like "you can have this done by <very soon>, right?"
>frontend created by fellow developer is a garbled mess of repeated code and questionably implemented subpages, frontend dev apparently copies CSS from Figma and pastes it into new non-reusable React components as envisioned by designer, I am tasked with making sense of the mess and adding in API consumption, when questioning boss what to do with the mess I am often told to discard stuff that the frontend dev has made and just reuse his styling; all of this on top of implementing the backend feature that a previous developer wasn't able to do
>specs change along the way, I had been using a library as a helper in some part of the original feature, now the boss sees that and (without further testing the library) promises CEO that we'll add that as a separate subfeature, but the performance of the library is garbage for larger inputs and causes problems, is basically shit that might not have been shit if we had implemented it ourselves, however at this point CEO has promised new feature to some customers, all the actual sense of responsibility falls upon my hands
>marketing folk see halfway done application and ask for more changes
>everything is rushed to launch, plenty of things aren't implemented or are done halfway
>while I'm waiting for boss to deploy, I'm called up to company office by CEO, and get new task that is pretty cool and will actually involve assessing various algorithms and experiment with them, rather than just stitching API calls and endpoints together, it involves delving into a whole new field of CS that I never had the opportunity to delve into before
>start working on cool task, doing research, making good progress
>boss finally deploys feature I had been originally implementing
>cut corners of original boring insane feature start showing up, now I have to start fixing them instead of working on cool task, however the cool task also has a deadline which is likely expected to be met

I'm not sure if I'm having it bad or not, is this what a whole career in software development will look like?

Today I created some reusable clean decent code to replace the random chaos in a huge project and then realised I had 3 options:

1. Sort out every instance to use the new code. This is very high risk because the project is both a shit show and has no tests. I don't have time to manual test or write unit tests on so much stuff.

2. Move over only some so that I can manually test. Still no time to unit test (management is fucked on their priorities). This will fuck the project even more since i will never get time to revisit this and adds yet more inconsistency and chaos to a project on its last legs and has this problem in droves.

3. Leave the project fucked

\_(^^)_/

I'm veering towards option 3 these days.

Praised be the developer/customer! 6 hours listening to him how HIS WAY is the ONLY way to write clean and reusable code! And teaching us how to write HIS way!
No matter how it ignores normal conventions, his way will ALWAYS be the better one! And to everybody who codes otherwise... we call them WRONG!!!!!
Anything you would like to change? NO! We will write it the way "WE thought it before" (I think he meant "HE thought" and impose into us... but... well, I guess I'll have to endure...)

It is the first meeting for this project, and I already want to jump off of a bridge :)

what's up with backend devs getting on rants about frontend frameworks? Don't they use frameworks for developing their precious servers? or do they just write the whole thing from scratch?

Shit tards, frontend development is evolving and for the better, we've got awesome frameworks that help us reduce the amount of code we need to write to attain a functionality and in a way that reduces headaches when building a large application and gives superb consistent performance because the code has been production tested a million times! yeah you can use js to build a frontend because its JS it's what it was designed to do, but tell me how reinventing the wheel everytime you make a frontend is useful, and how that is maintainable in the long run when building a large production frontend?

The modern frameworks, help us write modular and reusable components that can be shared and used by anyone for any of their application. They are arming the web with capabilities that are close to what native apps offer and still you keep bitching about it.

!rant
Finally set my first big ticket to "QA" and I hope it get's through. I put in a lot of work and it feels nice to have accomplished something.
But now I'm sitting here, waiting for another ticket to float in so I can do something. I've been sitting here all day and I'm writing reusable code snippets for VS Code so I can use them in the future.
Does this happen often in the life of a developer that you have to wait a few days until you get to do something meaningful again?

You work in a team, for a team to move forward successfully the team should work in sync. A team always has a goal and a plan to get to it. There are times when the team needs to take a different direction therefore the set path should always be available for change because our environments dictate it.

We all have different styles of working and different opinions on how things should work. Sometimes one is wrong and the other is right, and sometimes both are wrong, or actually sometimes both are right. However, at the end of it all, the next step is a decision for the team, not an individual, and moving forward means doing it together. #KickAssTeam

The end result can not come in at the beginning but only at the end of an implementation and sometimes if you’re lucky, during implementation you can smell the shit before it hits the fan. So as humans, we will make mistakes at times by using the wrong decisions and when this happens, a strong team will pull things in the right direction quickly and together. #KickAssTeam

Having a team of different opinions does not mean not being able to work together. It actually means a strong team! #kickAssTeam However the challenging part means it can be a challenge. This calls for having processes in place that will allow the team members to be heard and for new knowledge to take lead. This space requires discipline in listening and interrogating opinions without attachment to ideas and always knowing that YOUR opinion is a suggestion, not a solution. Until it is taken on by the team. #KickAssTeam We all love our own thinking. However, learning to re-learn or change opinions when faced with new information should become as easy to take in and use.

Now, I am no expert at this however through my years of development I find this strategy to work in a team of developers. It’s a few questions you ask yourself before every commit, When faced with working in a new team and possibly as a suggestion when trying to align other team members with the team.

The point of this article, the questions to self!

Am I following the formatting standard set?

Is what I have written in line with official documentation?

Is what I am committing a technical conversion of the business requirement?

Have I duplicated functionality the framework already offers?

I have introduced a methodology, library, heavily reusable component to the system, have you had a discussion with the team before implementing?

Are your methods and functions truly responsible for 1 thing?

Will someone you will never get to talk to or your future self have documentation of your work?
Either via point number 2, domain-specific, or business requirements documentation.

Are you future thinking too much in your solution?

Will future proof have a great chance of complicating the current use case?

Remember, you can never write perfect code that cures every future problem, but what you can do perfectly is serve the current business problem you are facing and after doing that for decades, you would have had a perfect line of development success.

My coding style is mostly influenced by good old personal preference, but also because of a certain internship where there was a lot of gain to be had by making everything as reusable and testable as possible.
I guess you could say my motto is usability, readability and flexibility:
I like tidy, reusable code with an emphasis on keeping code readable. I've always liked modular things I guess...
And I despise two things: curly brackets on the next line and spaces for indentation... But way worse is having no brackets at all (looking at you Python): it's clearer to have lower-level code inside some sort of "container" markers i.e. brackets (also gives more IDE functionality like color-coding hierarchically).
Indentation should always be tabs so anyone can have their own width of indentation set through their IDE, making it way more accessible to fellow colleagues!
And I also like having parameterized code over hard-coded functions: way more flexible.