Forgot an important one.
Learning how to identify the current bottleneck made it easier to focus on the most important thing.
159 karma · joined May 25, 2012
Learning how to identify the current bottleneck made it easier to focus on the most important thing.
Learning the key combos for whatever editor I’m using made it much faster to write, edit and manipulate code.
Learning basic bash and Unix programs like grep, awk, find and xargs made it a lot easier to write throwaway scripts to automate things that used to be tedious when done manually.
Learning how to identify the current bottleneck made it easier to focus on the most important thing.
Learning how to identify and talk about the tradeoffs I’m making made it easier to avoid rework.
Learning how to run containers, originally using docker and now podman made it easier to get whatever version of whatever program I needed quickly.
Learning how to debug and divide problem spaces made it easier to overcome problems.
Learning how to respond to incidents made it easier to get things working again.
Learning how to automate builds and deployments with CI/CD made it easier to focus on the code.
Learning how to use observability tooling made it easier to understand what normal looks like which in turn made it easier to understand when and why things weren’t normal.
Learning how to learn a new code base or tech made it easier to get up to speed when starting or joining something new.
Learning how to identify and focus on the next most important, smallest problem made it was more to produce value.
Learning how to work out what was important to stakeholders and co-workers made it easier to tailor my message and get buy in.
Learning how to mentor and coach made it easier to get things done as there were more experienced devs around me.
Learning how to trust in others made it easier to produce great things with great people and love what I’m doing.
Learning when to shut up is something I’m still figuring out.
In environments where vulnerability scanning of docker images used is important, running anything in production that isn’t stored in a docker registry kind of breaks things.
This approach also won’t work with container orchestrators like Kubernetes, ECS, Lambda, CloudRun, etc.
Where I can see doing a docker build of a small layer that just sets file perms potentially being useful is for container based dev environments to be ran on laptops and workstations.
If third party app stores were allowed, some vendors OPs parents need to use would likely only publish their apps on a different store. I would not enjoy helping my parents navigate going to the MS store for Office, the Facebook store for Instagram, the Google store for maps. The lack of fragmentation makes this much more approachable for them.
This is not a defence of the current system. That has many other problems.
One is your options for doing forensics on Fargate. AWS manage the underlying host so you give up the option of Doing host level investigations. It’s not necessarily worse as you can fill this gap in other ways.
Logging is currently only via CloudWatch logs so if you want to get logs into something like Splunk you’ll have to run something that can pick up these logs. You’ll have that issue to solve if you want logs from some other AWS services like Lambda to go to the same place. The bigger issue for us is that you can’t add additional metadata to log events without building that into your application or getting tricky with log group names. On EC2 we’ve been using fluentd to add additional context to each log event like the instance it came from, the AZ, etc. Support for additional log drivers on Fargate is on the public roadmap[1][2] so there will hopefully be some more options soon.
[1] Fargate Log driver support v1 https://github.com/aws/containers-roadmap/issues/9 [2] Fargate log driver support v2 https://github.com/aws/containers-roadmap/issues/10
~17 years later that has definitely been my experience.
It’s possible to be very productive in a language after 6-12 months. The code might be decent, or with some talent and hard work, even good. It really doesn’t take all that long to learn enough to produce some cool things. However, I’m almost certain that if you look back at the code you write today in 12 months, 5, or 10 years, you’ll see many things you’d do differently. This is partly because In 10 years you will see many more problems, and solved them in many different ways. Personally, that’s one of the things I really love about this field.
OP why are these needed? Can you remove them?
In other words, a Dockerfile specifies what you want to build, and a compose file specifies how you will run it.
If it's a Rails app, two things spring to mind as first things to try once you have profiling in place:
- lower the number of web server workers and/or threads (depending on what you're using)
- Ruby 2.1's garbage collector is really not well suited to web apps because it will often promote objects from a single request to the long-lived generation, even though they will not be needed again. Going from 2.0 to 2.1 nearly doubled the memory usage of one of our apps. 2.2 is doing much better.
You might also want to see if you can offload any processing of tasks that can be queued using something like Sidekick or Resque.
There's a bunch of other things you could do but you really need to work out why your app isn't performing as you'd like first.
As long as there is enough difference between the current number of instances in service and the maximum size of the ASG, existing instances won't be terminated until the new instances are passing healthchecks and the load balancer is sending them traffic. If the maximum has been reached, enough existing instances will be killed to provide room for the next batch of new instances.
- Get a large (27" in my case) monitor so I can have the text large without having to constantly zoom in. High resolution + higher DPI is easier on the eyes than getting big text by lowering the resolution.
- Learn a terminal based text editor (Vim or EMacs) and get good at using the terminal. Many GUI based applications, particularly IDEs have limited options or don't work well with larger text sizes. Working within a terminal makes developing less "visual" while maximising the amount of information on screen. Now I spend 80% plus of my day in a terminal and my eyes are significantly less tired at the end of the day.
- Use a tiling window manager. On OSX I use Slate (https://github.com/jigish/slate), or on Nix you could use something like XMonad. The screen-snapping stuff in recent versions of Windows is helpful too. The idea here is to rely on the mouse as little as possible.
- use a dark color scheme. I like Solarized-dark but there are several other good options.
- pick an easy to read font. I use Menlo and have the size up around 32pt.
- use a terminal prompt that makes it very clear where the prompt is when scrolling back through history. I use this one https://gist.github.com/agnoster/3712874
- get an adjustable monitor arm so you can bring the screen closer to you without craning your neck. I've had the same one for 15+ years but am planning on buying one of the Ergotron ones in the next few weeks
- use f.lux to take the bright blue tint out of screen colors https://justgetflux.com/
- work in a room lit by lamps positioned so that they don't add any glare.
- if you often find yourself working at the same screen as other people, set up a second monitor in mirror-mode or investigate using TMux if you're both in terminal editors so that you can have your terminal configured so it's comfortable for you, and so can your partner.
I'm happy to provide more info on any of this.
The answer to all three questions is the same: virtually never. Instead, we use Cloudformation and the AWS CLI/SDKs for various languages to script configuration and deployment. We do use the web console to view the current state of our infrastructure though.
2. Macs are popular for iOS, Android and web development so they're a good choice.
3. It's possible but it will be a lot of work. I don't have any recommendations on beginner courses. Maybe check out reddit.com/r/learnprogramming
4. As you implement your MVP, try to break each problem you face into smaller, manageable chunks. It's much easier to solve several easy - medium difficulty problems than 1-2 hard ones.
Ask your client these questions: - what does the business do? - who are their customers? - what problems are they currently facing because of their current website/lack of a website? - what goals are they hoping the website will help them meet? - how will success of the site be measured?
The client is paying you to bring technical expertise that they don't have in house. To do that effectively, you need to understand their business.
At some point you will have to talk to them about the design. If they suggest site designs, ask them what they like about it - this may require comparing to other similar sites as they may not be able to explain why they like a design. Also ask them why they think the design is a good fit for the image of their company. More complicated designs often take more time, and therefore cost more but they aren't necessarily good. Simple is almost always better.
2. I tend not to discuss the technologies used unless the client shows interest. Certain related things will need to be discussed: anything that costs them money (hosting, domain registration, etc) and anything that involves dealing with a third party.
Resist the urge to futureproof. Don't build code to support things that may never happen. This will help kep the code simple which make it easier to maintain and add to in the future if one of those hypothetical requirements becomes a real requirement.
3. This is tricky for everyone but especially hard when you're first starting out.
First I have an initial chat with them to answer the stuff in 1. above. I don't charge for this. Then I respond with a proposal that outlining the core features of the site. This is the minimum set of features that I think will address their most important goals - doing just this stuff will give them the most bang for their buck. I also include outlines for optional features that could be added once the initial feature set is in place. For each core feature, I provide a very high level estimate that covers everything needed to get that feature deployed and running as a live site - design, coding, testing and deployment. Resist the urge to be optimistic in your estimates - things will take longer than whatever number you're thinking of now. It's better to be a bit conservative with the estimate and set expectations early than it is to miss your own deadline.
For optional features, I just give an indication of the relative effort involved compared to other optional features. If this is questioned I explain that by the time we implement those features, the understanding of the problem we're trying to solve will have changed enough that it makes any numbers given now misleading.
As this is your first project, I'd recommend working on a per hour basis rather than a fixed price for the project. Generally, charging based on the value you deliver to your client gives better results than basing the rate off other roles you've had but that kind of requires you proving yourself with a couple of projects first. I'd probably go with $20-25 an hour for this one but revise this for any later projects.
You'll need to establish some kind of contract with your client. The specifics of this can be a bit different in different areas though. Google for developer or website consulting agreement for some samples.
The best thing you can do to make sure your client does not feel like he's being overcharged is to convince him that he's getting good value for money and the best way to do that is to show that you understand his business and that you're helping him solve his problems and reach his goals.
The best thing you can do to make sure that the client does not think that the project is taking too long is to regularly deliver features and communicate your progress to him. Don't go silent then give him everything in one go at the end. Give estimates that you can meet, and then meet them. When it looks like you aren't going to meet an estimate, let him know and recommend how to proceed.
Have fun. You're about to learn a lot.
TLDR: Aside from the technical, freelance consulting is mostly about managing expectations and perceptions.
Norman Borlaug developed semi-dwarf, high-yield, disease-resistant wheat varieties credited with saving over a billion people from starvation.
Ignaz Semmelweis discovered that it's a good idea to wash your hands before carrying out surgery.
One of the interesting things about software development compared to many other professions is that the field is still so new that people can have very successful careers without having done a degree.
Another interesting aspect is that software affects virtually every other field so there's opportunities for people coming from all kinds of backgrounds.
Given your current situation, I'd approach it as a hobby for now. Try to come up with little projects that are related to other things that interest you, or that would make your current job easier.
As you learn more and gain experience, try to apply your new knowledge to slightly more complicated projects, or to improve or redo past projects. You'll find the whole thing more rewarding if you do it in a way that you can get some direct benefit out of your work. The trick here is picking the right problem to solve. People often pick something that seems simple on the surface only to get discouraged and give up when it turns out to be more complicated than they first thought. Just try not to bite off more at once than you can chew.
Keep your eye out for opportunities to help solve other people's problems but again remember to keep it simple. Also keep in mind that their view of the problem and how it should be solved will be very different to your's. Learning how to manage this is a very valuable skill in itself.
Eventually you'll get to the point where your knowledge of development is that you can charge other people to apply your expertise to solve their problems for them. That's all a professional developer is.
At some point consider doing some more academic or abstract study. You don't have to do this right away, or formally at a college or school. The courses on sites like Udacity, Coursera and MIT Open Courseware cover a lot of the same stuff. While these courses will dive into areas that you won't use every day, they do give you a good overview of how everything fits together so you know the right questions to ask and the right places to look when you hit unfamiliar problems. You can get a long, long way without doing this at all depending on the type of development you want to do though.
Software development is a huge field so just keep learning whatever interests you and keep applying it to solve problems in other areas of your life. You'll get to enjoy the benefits of what you make and with persistence might one day be able to sell what you've learned to other people.