Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
mkdir new_project
cd new_project
git init
**Reflecting on my life and current workload**
cd ..
rm -rf new_project.
3 -
I always like to approach a new coding project by concentrating on the data model first. I've seen a lot of projects built on extremely convoluted database structures and it really hurts because it makes it hard to add new features to the project.
So I look at the requirements of the new project and try to come up with a basic data model. Then I like to think about what logical future additions to the project could be. And using those, I try to see if the data model is flexible enough to be able to handle those additions fairly easily or if complex migrations or hacks would be needed to account for new use cases and features.
I think once you have a solid data structure and database technology, planning out an API or rest of the software is pretty straight forward. I like to create reusable pieces of middleware early on in the project which makes it easy to apply consistent functionality with ease to different API endpoints.8 -
1. Have idea
2. Write down features that thing should have
3. Make a wireframe design
4. Write down possible names for it
5. Open GitHub-Repo
6. Never start coding it
7. Cry5 -
Just fucking start it.
Don't stop before it is done.
Take breaks when needed.
And don't forget to have fun!4 -
open telegram
'hey guys i have a cool idea for a project'
"yeah thats a neat idea lets do it"
we get drunk on the first meeting and completely forget about the project5 -
KISS.
Keep it simple, stupid.
At the beginning the project is nothing but an idea. If you get it off the ground, that's already a huge success. Rich features and code quality should be the last of your worries in this case.
Throw out any secondary functionality out the window from day 0. Make it work, then add flowers and shit (note to self: need to make way for flowers and shit).
Nevertheless code quality is an important factor, if you can afford it. The top important things I outline in any new non-trivial project:
1. Spend 1-2 days bootstrapping it for best fit to the task, and well designed security, mocking, testing and extensibility.
2. Choose a stack that you'll most likely find good cheap devs for, in that region where you'll look in, but also a stack that will allow you to spend most of your time writing software rather than learning to code in it.
3. Talk to peers. Listen when they tell that your idea is stupid. Listen to why it's stupid, re-assess, because it most probably is stupid in this case.
4. Give yourself a good pep talk every morning, convincing you that the choices you've made starting this project are the right ones and that they'll bring you to success. Because if you started such a project already, the most efficient way to kill it is to doubt your core decisions.
Once it's working badly and with a ton of bugs, you've already succeeded in actually making it work, and then you can tackle the bugs and improvements.
Some dev is going to hate you for creating something horrific, but that horrific thing will work, and it's what will give another developer a maintenance job. Which is FAR, far more than most would get by focusing on quality and features from day 0.9 -
Like a bad relationship
Be really excited for the first month or so then once the new car smell starts to fade, lose interest and dump it.3 -
1: Open my IDE
2: Think about how much I have to do
3: Try to do it
4: Eventually switch to YouTube2 -
Method 1:
1. Read others' people answers on wk70
2. Apply
3. ???
4. Profit
Method 2:
1. cd <ProjectName>
2. git init
3. dotnet new sln
4. dotnet new console #or webapi/lib
5. code .
6. git commit -m "Initial commit"
7. git remote add origin <github link>
8. git push origin master -u
9. profit1 -
I start with the features I want for sure and then i start looking at what data I really really need to store. Then I start looking at what data I don't have to store because of privacy reasons anyways.
Next stop is looking at the security.
When that all looks good, I simply start programming!5 -
1)Get Project/idea
2)Look for the most suitable tech
3)Draw out all the functionality
4)Break into milestones
5)git init
6) git commit
7) Start
8) Test
9) Complete
10) Feel like a King7 -
Today's project was answering the question: "Can I update tables in a Microsoft Word document programmatically?"
(spoiler: YES)
My coworker got the ball rolling by showing that the docx file is just a zip archive with a bunch of XML in it.
The thing I needed to update were a pair of tables. Not knowing anything about Word's XML schema, I investigated things like:
- what tag is the table declared with?
- is the table paginated within the table?
- where is the cell background color specified?
Fortunately this wasn't too cumbersome.
For the data, CSV was the obvious choice. And I quickly confirmed that I could use OpenCSV easily within gradle.
The Word XML segments were far too verbose to put into constants, so I made a series of templates with tokens to use for replacement.
In creating the templates, I had to analyze the word xml to see what changed between cells (thankfully, very little). This then informed the design of the CSV parsing loops to make sure the dynamic stuff got injected properly.
I got my proof of concept working in less than a day. Have some more polishing to do, but I'm pretty happy with the initial results!6 -
• Plan out everything by taking notes on the rough functionality of the project and how it could be done in a preferably simple way
• Writing code, but documentating it while doing so
• Also trying to write clean code so it can be more easily built upon
• Also keeping everything simple. If I'm using nasty, unreadable one-liners because of efficiency advantages, I'm putting a comment there for what could alternatively be used + explaining it
• Abandon it because side projects never get done1 -
How I should approach a new project:
- think about data design
- draw some tables
- configure relations
- create data structures
....
How reality proves I'm a donkey:
- builds random table
- works on models, with random querys
- realizes things get to complicated and relations are broken or tables need duplicate logic
- starts thinking about 'good' design
- draw some tables
- configure relations
- create data structures
.... -
1) Heck yeah, great idea
2) Sit like 60 minutes there thinking about a name for the project
3) Build the basics
4) ..meh fuck it2 -
Work out the major requirements,
Identify platform(s) and environment best suited to project,
Design and develop around core features,
Allow 6-12 weeks for scope creep and the additional BS features,
Build, test and deploy in a week or two to meet unattainable deadlines.
Spend new couple of months refactoring and fixing everything. -
For a new project I first try to get an overview about the specifications, hosting and platform.
Depending on this information I decide which language and frameworks (if any) to use.
Basically always the first part I create is the backend, so I have all the data interfaces ready. For web stuff Postman is really useful.
Later on I start with the frontend, get myself really angry because I hate frontend.
Then I get into a hate-overdrive because browsers suck and I delete everything and quit.1 -
First check if anybody else has done it.
Second check if theres a convoluted way to chain existing projects to do it.
Third buy some whisky and down half of it.
Fourth plan it out
Fifth create directory and open vim1 -
Design on a Paper: "The more time you spend on papers, the less time you spend on your system" - Random programmer3
-
Couple of jobs back we got bought out by that massive shipping company with the red and yellow colors.
We used macs and some high up moron decided it was a good idea to put on domain policy restrictions on our macs, but developers can't work without admin access so if we wanted to keep said admin access, we had to sign a written agreement indicating that we were not allowed to do certain thing, like change our wallpaper or install personal music players, you know like Spotify, which at the time was what most of us used.
Now this was just a nice cherry on the cake of stupid descision that was making me rethink working there. Thanks to the high demand for skilled front ends, it was 11 am when we got this, 3pm I had comnfirmed my interview for the next day.
An hour later our manager called us all in to explain this was BS formalities. Well too fucking late, learn to communicate you dumb shit.1 -
*Have idea.
*Start thinking about it.
*Start seriously thinking about it.
*Push yourself to do it.
*Have a mini unconscious panic attack that tells you you're gonna fail.
*Do something else completely unrelated to what you wanted to do.
*Feel good about the meaningless shit you just achieved.
*Recognize you're procrastinating.
*Try to stop.
*You can't cause you're stupid and lack the control and discipline to trick your own mind.
*Watch video about how to overcome procrastination.
*Get a more firmer understanding of it.
*Realize you're a helpless piece of shit.
*Cry till dead inside.
*Resume daily mindless shit.1 -
Here's my flow:
1. Sit at my desk and contemplate the Universe
2. Sort out specifics by pacing back and forward
3. Draw like a mad man
4. Copy an old project and change a few lines of code
5. Go home happy that the Universe is safe once again
;)2 -
1. Get an idea
2. Plan the structure to use overengineered solutions
3. $ git init
4. Setup the barebones
5. $ git commit -am "initial commit"
6. Forget the project for the next several months, until another idea pops out and you visit your github to setup a repo for the new project and rediscovers this miserable project's repo
7. Back to 1, repeat -
#include <iostream>
using namespace std;
int main() {
cout << "Hello world" << endl;
}
If it works, It's time for a coffee break!! :)12 -
Immediately start coding every feature all at once as fast as possible. After about a week I realize the architecture is so bad I can't continue so I stop, and design the architecture properly so it will scale. Then I delete everything I had and start from scratch. Finally after about another week I lose interest and let it rot in the side project graveyard.
Rinse and repeat. -
1st week of doing proj: "hello there sexy, u are gonna one beautiful project. ill be doing all my best to finish you and you may actually one of my best projects."
after a month: "aaaaa ERRORS EVerywhere, tf is wrong with u. imma start another project if u dont start running properly like i planned"
after another month: *procrastinates while debugging* "yaass it works now, lets finish u baby"
takes some time to finish projects but if theyre really good, i usually finish them, especially when i am motivated and full of determination.2 -
Our approach is to get a loose feel for what the client wants, lift some visuals from Theme Forest then spend the next few weeks persuading the client to use our crappy server rather than their preferred AWS solution. Then once the project is behind schedule we break the work down into disparate tasks each of which gets a single line brief from the PM (such as 'create admin' or 'do css'). These then get assigned to different devs with no consideration of their skillset. The PM is available for 10 mins every day to answer queries, the rest of the time our devs are expected to work autonomously. Meanwhile we'll tell the client that we're back on schedule and arrange a demo for an impossibly short deadline. We have the mantra ”dont worry about it” which the PM uses to quash any dev's concerns up until the day before the deadline at which point we'll swap some devs on to unrelated work whilst others concentrate on getting "just the pages the client wants to see looking right" (we have a policy of making it look like it works before it actually does.) Following the demo we will announce all the missing features we had forgotten about from the initial undocumented agreement and set the project aside whilst we service another client.2
-
I begin with the optimism and the joy that I am creating something new that will improve people's lives.
I listen to the user and analyze the current process in depth.
I try to suggest additional value to the system for the users consideration. Sometimes they do not realize we can improve 10x rather than 2x.
I learn what the users goals are and what they want out of the system. We think about reports and downstream value. Sort of working from the end to the beginning (data ingests and upstream processes that will feed the system).
After the user signs off on the requirements and deliverables and I have a realistic project plan I begin to code.
It works and has worked for me every time for a long long time. -
There are a couple of things I like to do before sitting down to code for the first time on a project. Throughout all of this I'm (sometimes unconsciously) planning out the project.
- Clean the house;
- Buy groceries;
- Buy/prepare food & eat;
- Arrange everything on my desk so that everything looks slick as fuck;
- Actually sit down to do something;
- Realize it's past midnight;
- Go to sleep.
Sometimes I wonder if I have OCD...3 -
1. Put idea on roadmap
2. Work out simple implementation
3. Productowner-san, please notice me.
4. Other devs pile on cool but complex ideas
5. A 4 hour meeting later, original simple idea is rejected because it's "out of scope" and there is "no consensus about implementation"
6. I already built it during the meeting
7. I sip my coffee while I enjoy the annoyed gasps as coworkers receive PR notifications.
8. FUCKING DARE TO REJECT IT COCK SUCKING SCRUMBAGS.2 -
-get an idea for a game
-lay down the plan
-prototype with basic shapes
-max hype
-realize that I can't draw/model to save my life
-give up3 -
I usually start with a MindMap where I try to write down every bit of the idea.
I then try to set requirements and set the tools/frameworks I want to use.
Next step would be data model and then git started ;)2 -
After watching YT-Videos about the Language/Framework/... , I start during a long weekends night with a fresh Spotify-Playlist. 😁
The few first days are always the most productive ones... Until you loose motivation... 😒
Do you hear music when coding? Sometimes I think, I could be way more productive when I just code without it. Do you agree?1 -
Most of my projects are based on one or few existing platforms, so core technology considerations are usually quick.
I like to wrap my head around the user stories first and then decide should this be more of a future-proof code, ie more extensible/generic, or just a code that will serve a few specific scenarios but would allow me to get it over with quickly. -
Depends on the project.
If it is a full application I usually start with what information it will handle.
Then either sketch out some database or some pages depending on how much info I got and if I got any good examples.
The less info I have, the more I try to focus on use cases and workflow to try to figure out what data will be needed.
But for more niche projects, like supportive library, ex parsers, I either mock some test in linqpad or look for similar examples online to flesh out the idea.
But I tend to very quickly fill out the basic shape and try to get something that can be tested.
Then I can find if I need to rethink it. -
I always start with a personal need. I can't really commit to projects that I wouldn't use myself. Once I have the need, I spend days trying to Google if it exists, and if not, I go ahead. (Then sometimes I find out later that it does exist, it's just that they suck at SEO.)1
-
Open a new to do list
Start listing
Go into too much details
Much more details
Sleep at a very late time
Wake up with another genius idea
Repeat -
6 months of procrastination whilst trying to decide whether it will be worth doing, and whether I actually have enough skill to do it
-
I start on paper by describing what a basic version of the code should be able to do. Then I write down some ideas of improvements to the code, more functionalities, etc. This allows me to write the basic code already thinking of what I want to add next.
Not that it matters anyway, 95% of my codes never lead to a working product 😅 -
I prefer it doing 2 tasks parallely during the initial phase of requirement gathering and design phase.(makes more sense if you are working extremely new system and framework)
1. Keep collecting requirements from clients and understand them.
2. Collect different designing aspects for the project and parallely, build a POC for 2 purpose: to get hands into the new Framework and also as a demo to clients. Working on POC helps in 3 ways: Improving understanding of requirement, improving framework knowledge, and playing around with code whenever bored of designing and reading tons of existing designs..
3. Once primary requirements are clear and fixed, analyse all different designs, if possible I setup meetings with senior devs, principal engineers (they help a lot when it comes to reviews on scalability and reliability of a design)
4. The above design is mostly architectural level. Once design is fixed, then I start taking each component and prepare a detailed implementation design. (Notice that whenever I am bored of designing, I spend sometime in building POC)
5. In detail design, I focus on modularity and flexibility. Anything defined should have getters and setters for example. This will help you reuse your code. Keep the interface between components in your design as generic as possible, so that in case your MySQL is change to Postgre or NoSQL, your design should be able to adapt new features..
6. Instead of building entire project, define feature targets and deliver small features.. this will help you to be in line with the requirements with minimum deviation. -
I start with the broad concept first.
"In the end, the application needs to do <this>. Okay. In order to get to <this> the application first has to know <that>".
Then, I just keep breaking this down until I get to the bits and pieces. I see the forest and then zoom in on the trees.1 -
1) Have a great idea
2) Ask a friend who knows how to code to do all the work
3) Get rejected
4) Repeat until you find a sucker
5) Profit 💰 💰 -
I start by diving straight into the code. A blank brand new file in whatever language I have chosen to create my project in. If it's a language I'm unfamiliar with, I'll start with some templates of getting started (for example, I wanted to make a node.js application with a connected website, so I found some code using express to link the two together).
Once I've started, I'll eventually create a text file for ideas which I may or may not plan to implement later. If a particular feature is rather complex, I'll draw it out on my whiteboard, giving me a visual guide to help me.
My main aim is to simply get a "foot in the door"; once that's achieved, it makes working on the project much more enjoyable. I tend to turn it into a bit of "play" by coming up with suggestions which I would probably not implement in my final design, but add just for the fun of it. If I chose to drop those ideas, I'll save the code - chances are, I would have learnt something new in the process (For example, I learnt how to perform GET requests and figured out what cURL was for the first time by simply adding a "dad joke generator" to a discord bot, just for a laugh) -
mkdir ~/Documents/Development/<insertnewprojectnamehere>
cd ~/Documents/Development/<insertnewprojectnamehere>
nvim <insertnewprojectnamehere>.cc -
Come up with an idea of yet another alternative to React that'd be supposedly faster and smaller.
Stop myself. -
Since I started the process has been something like this:
def new_project():
Have an idea;
for implementation in idea:
search("how to/
{implementation}");
if idea.works():
me.celebrate()
else:
me.die_a_bit_inside() -
It usually starts with a project, a CI pipeline, unit tests, deployment guidelines, and wait - oh crap - what am I building again?
-
1) git init
2) organize the structure of the project and check what features you need
3) google the name of the features and search a module that solves it
4) follow the module's tutorial step by step
5) compile the code
6) notice it doesn't work
7) StackOverflow, github, Quora, emails with insults to developers, parcel posts with bombs, try suicide
8) ascertain you could have spent all that time in funnier or more productive tasks
9) right click on project -> delete
10) forget the previous experience
11) goto 1 -
I always start a new project like: Copy & paste a similar project and edit its Readme.md file (and perhaps pom.xml) and delete all the other files I don't need right now 😉
-
My advice: simply code and work out things on the fly.
You will maybe need to rewrite something, but thats ok. The more you do on the fly, the better!5 -
1. Get excited by what it'll be able to do
2. Think about the tech stack
3. Lay out its features
4. Procrastinate -
Collect project specifications & details.
- order by relevance.
List & install dependencies (possibly spin up a vm).
mkdir ~/Code/{lang}/{framework?}/{project}
Bootstrap skeleton & scaffold.
- ensure functional base.
Iterate specs list & create test case(s) one at a time, going: test => minimal to pass => refactor => next(repeat_cycle)1 -
new project != new wonderfull creative ideas but rather new project = lots of procrastination and over analyzing
-
It normally starts with installing a new framework, either via composer or npm, then several hours of reading documentation, before giving up for the day. I think to myself I'll pick that up again later...
The good thing is I always learn something from it I can use in other projects. -
1. Sum up all the behaviours/functionalities the program should have
2. break each functionality down to the data/procedures that it uses(mindmaps can help)
3. get an understanding of a naive implementation and implement it (fast)
4. collect improvement opportunities (opitimization/simplification/expansion) and get a deeper understanding of the solution
5. spend a few days on some real life issues
6. improve the naive code, if appropiate, start all over -
Usually an idea comes up in the back of my head... Then i wait. After some time, the idea comes again. Now ill think about it, when i lay in bed, when im in a train, everywhere. Ill think about the technical implementation. How ill present it to someone else. To my boss. To my little brother. I think about the counterarguments, ill simulate discussions in my head, how ill defend it.
And then, one day, while thinking about it, ill start writing it.
Edit: Its like my brain needs enough entropy to do something. Then it works, then it generates entropy again, eg youtube, gaming, working on something else, dreaming etc -
Come up with a cool idea and the concepts I want to learn by making the idea. Download IDE/editor if I don't have it. Open that bitch up. Crack a beer and my knuckles. Yep, nothing can stop me now. No distrac- damn my shoes are shiny. What was I doing again?
*as I am laying down to sleep* oh no. I forgot to code that cool thing AGAIN. -
"hey that's a nice idea I have here"
"Oh wait, there's school. It's gonna wait 10 more months, plus I have 5-6 projects going on" -
Spend hours of many days organising and structuring the architecture just in my head. Often go to bet thinking about it and dream about it too.
Sometimes I record audios on telegram to myself so that I can remember what I thought, I never listen to them though.2 -
This depends mainly on the programming language with which I want or have to develop a project.
I like to use Behat for PHP and other simple things. At the moment I only have clients who want to implement projects in PHP. God knows why.
For more complicated things I like to use yeoman, but I have to say that there are also a lot of horrible generators, so I follow the official instructions more often.
Otherwise, the usual procedure:
1) git init
2) Planning of features and functions (if not already specified by the client)
3) Select frameworks (mostly necessary)
4) Start programming
5) Commit often
6) Commit often
7) Commit often -
Frontend: $ vue init ducksoupdev/vue-webpack-typescript bodywork, setup some linters, formaters and ci and I'm ready to go
Backend: $ cargo new --bin gears, setup some linters, formaters and ci and I'm ready to go -
Realize how complex it is to build and the time it would take, then when I check how many similar things to it already are on the market, I feel like there's no reason to do it.
-
I start projects by researching the latest technologies and architectures and learning them, and usually decide to start over with something even newer pretty soon after. No wonder I never finish anything 😋
-
I first try to figure out why I really want to build this and (if the project is intended that way) why someone would use it.
Then I strip the idea down to its bare minimums so I know what I should build for it to be of any value.
And then I start building until I no longer think it's worth working on the project.
For instance:
I am kind of surprised to see that in a world where cloud and apis become more and more leading, there isn't really a commonly accepted and flexible api management platform.
There are some cloud based platforms out there that can be configured using some interface but why is it like that? Surely you aren't going to deploy multiple versions of your core with different platforms right?
That's where my latest project comes in. I want to create an on-prem api management platform which you configure to work with your api during development. Then you can deploy it to any infrastructure alongside your core api.
This way you:
- are not bound to a specific cloud
- don't have to worry about security and firewalls
- get user management and rate limiting for free
I will probably create a collab for this once the platform is mature enough.1 -
Got a new idea in mind...by the time idea reaches pen and paper and computer ( I hear a voice back of my head...."Is that what you were think of, think of something NEW it's already implemented!")
-
Overestimating the solution, trying it, failing, underestimating it, errors, "this is impossible", quitting...😔
-
I write a hello world and then start importing libs and packages on top. Then I adapt the hello world to test those libs and packages. The entire thing is one big sanity check. The logic is done in increments as well.
Is this bad? -
Gets really excited thinking about possible new project.
Starts work on it.
2-3 days interest still there.
Gets bored after and puts project on halt.1 -
* Find something you don't really know or haven't used in your language of choice
* Push that feature in your architecture
* write shit code because the feature really shouldn't be there -
I imagine what I want it to do at its core and what I need. Then research and get to work!
Started building a YouTube downloader using nficano's Pytube library.
I know there are a ton of them out already, but I am doing this to learn some Python and nuances. I tried YouTube-dl but that's more cli oriented and I've already built cli GUI wrappers before.
So the key I think is persevering even if it's already been done. By building this I'm learning tkinter, Python in general, and when I try to build this into an executable (so the user won't need to have Python) I'll learn how that works too. -
I think whether this is even a project that should be done NOW
or if there's some critical dependency that some monkey just happened to have forgotten to tell me... -
Start a project with new idea that will totally work. Rinse and repeat every 3 days, 3 weeks, 3 months 😅
-
I get too excited, make a plan for future-proof infrastructure, initialize project, code a lot of it, then it gets too cumbersome and impossible for single dev because it is future proof, I lose my interest and then most of the time the project gets even removed on Github eventually after sometime
-
1. write down requirements. what exactly do i want?
2. paint possible solution. how could the finished product look like? while doing this i think through each step of the application and often adjust step 1 until i think 'this is it'
3. design model. how could the database look like. what structure do i need?
4. define milestones. What to do first?
5. Start and keep 1-4 up to date -
Whenever there is a new project to work on, I get the complex parts, I work for 10 Hours a day. While others get simple tasks, go home on time.
Question do I take that as a compliment ? -
mkdir ChuckTesta or MyTestProject or something similar.
I always like to use a sandbox beforehand to experiment with technologies and get familiar with them before committing to an actual project repo. -
I start telling everyone about my cool new idea and start researching how to go about coding it to find that someone has already done it way better than I ever could. T-T
Or, I start coding it for a bit and then forget it ever existed for a few months and then remember it again and then work on it a little more and then forget again and the cycle repeats until I lose interest in the project. -
I get a paper and a pen and write down what I know I have to do, what I don't know how to do it and I suspect I don't know yet what I'll have to do.
For the parts I know I'll have to work using a new framework or new tools I try to create a proof of concept project I can reuse later.
I tend to write a bit in paper before coding just to wrap up my head on what I'll have to do. -
new project != new wonderfull creative ideas but rather new project = lots of procrastination and over analyzing
-
I start with a POC or a prototype to prove it can be done and to fart around with possibilities. Then I start refactoring the prototype into a full product.
-
Looking for something that exists and then decide to do it better or use the existing one. Why reinvent the wheel.
-
Think and stress about it and how I have other projects. Say fuck it and write a few lines. Leave it for a couple of days and either come back to it or completely forget about it
-
4 Step Plan:
1: Have a new idea
2: Work on it
3: Forget about it a week later
4: Pause project till forever! -
Well at home I have a whiteboard and on that white board I make a list of things I want the code to do, don't do, and any ideas possible to emulate then I grab a cup of coffee turn on some music and start
-
Start out by writing everything I want the project to do down in a text document. That way I can just go down the list and add features in order.
Top Tags
Weekly Rant
View